记一次Clickhouse的问题处理，报错：query execution time (39.17692568900305 seconds) is too long. Maximum: 20 rows to process: 549270975: While executing MergeTreeThread. (TOO SLOW)

实际问题很简单，就是执行SQL查询超时，默认的查询超时时间是20秒。

为什么20秒还会超时呢，肯定是技术不到家。本来是属于验证型的一个日志库，日志存储了5亿多了，是大文本的那种数据，在其他库下面早死了几百次了那种。所以clickhouse能够查询出来，都还算不错。

由于对Clickhouse掌握的不够深，建表的时候，并未在查询某条记录详细的时候，给where条件后的字段建立索引，但是数据表本身是分区表，有根据时间分区的条件的。对应的，时间字段也是有索引的。

查询频繁报错的信息如图：

第一步解决，就是处理这个超时的问题，超时，就设置更长的超时时间就可以了吧。

找了一圈，设置max_execution_time的值，由于不想重启服务器，找到一个方法，在SQL最后加一句：

settings max_execution_time = 120

120秒超时，再看的时候，执行SQL超时的问题解决了，但同时又出现了新问题：

Operation timed out after 20001 milliseconds with 0 out of -1 bytes received

这就是连接Clickhouse这边的连接默认也是20秒，所以只改了执行SQL查询的超时时间是不够的。

我这边用的是PHP的一个开源库连接的，设置一下连接超时时间即可。

$db=clickHouse::getInstance();
$db->setTimeout(120);

至此，可以查询出结果了，只是速度相对较慢，有二十多秒才出结果的。

后面，又仔细想了想，如果在where条件后面加上有索引的日期字段，是否会提高效率

当前，这个前面，我还尝试去给现在where条件后面的字段建立索引的，但是没成功。

最后，就是把where后面加上一个有索引的日期字段作为条件，并且放在前面，结果查询速度一下上来了，毫秒级了。

------------正文已结束，感谢您的阅读（折雨的天空）--------------------