count 浅析（2）

方案三：其他数据库

其他数据库的话首推 clickhouse，之前测试ch时发现执行count(*)速度非常快，截一张当时的PPT：

当然异构数据库最大的问题就是要解决增量同步。mysql 同步至 CH，目前大多数的方案是使用python工具，该方案还不成熟，相信随着时间推移会有更好的方案，届时很多 OLAP 或者 count(*) 业务都可以在 clickhouse 上进行。

小结

如果对行数这种实时性、响应性要求很高，而数据库本身也已无法满足，这时候才应该考虑去持久化计数。各种方案都是有利有弊，找到合适自己的才是最好的。

四. 关于查询成本

在测试count性能时，想到了select操作会涉及查询成本，于是特意把之前写的有关查询成本的内容贴了过来，希望可以帮到大家，也给自己做个知识点回顾。

执行计划

再额外看下mysql的查询成本，以一条sql为例：

SELECT
    *
FROM
    count_test 
WHERE
    var_col > 'var_co1123456'
AND insert_time < '2020-10-26 10:10:12'

这条sql不出意外扫了全表，可能是由于用了 select * 需要回表，开销较大。接下来改成索引覆盖的形式。

索引覆盖：

SELECT

执行计划显示还是用了全表。

索引覆盖+强制索引：

使用 force index ，让它强制使用时间索引：

执行计划用到了时间索引。

查询成本核算

核算公式：

cost = rows0.2 + data_length/(102416)

1. 全表查询成本

199644 0.2 + 9977856 / (1024 16) = 40,537.8

代入公式可以算出，全表的成本约为 40537.8

2. 各索引查询成本

通过 optimizer_trace 方式查看：

SET optimizer_trace="enabled=on";

SELECT insert_time FROM count_test WHERE var_col > 'var_co1123456' AND insert_time < '2020-10-26 10:10:12';

SELECT * FROM information_schema.OPTIMIZER_TRACE;

SET optimizer_trace="enabled=off";

然后看下走索引的预估成本

optimizer_trace 下全表查询的预估成本：

40540 和我们之前计算的 40537.8 差不多，这个值要远小于走索引的成本。

所以 mysql 在执行此 sql 的时候会使用全表扫描，都是基于执行成本来判断的。

全文完。

Enjoy MySQL :