方案三：其他数据库
其他数据库的话首推 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 insert_time FROM count_test WHERE var_col > 'var_co1123456' AND insert_time < '2020-10-26 10:10:12'
执行计划显示还是用了全表。
索引覆盖+强制索引：
使用 force index ，让它强制使用时间索引：
执行计划用到了时间索引。
查询成本核算
核算公式：
cost = rows*0.2 + data_length/(1024*16)
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 :
