如何提升count(1)的查询速度

[luckyfox]

• 系统版本 & kernel 版本：
• TiDB 版本：2.1.15
• 磁盘型号：
• 集群节点分布：
• 数据量 & region 数量 & 副本数：
• 集群 QPS、.999-Duration、读写比例：
• 问题描述（我做了什么）： 我的理解里有索引或者统计信息这个行数查询会很快，但一个几十亿行的表，要花2分钟左右才出结果。有主键。 有什么办法优化吗？我只是用户，所以其他的参数不是特别清楚。可以提供一些普遍的经验吗？谢谢

[飞与非-PingCAP (飞与非)]

可以通过 explain 看一下查询计划

[luckyfox]

没有走索引。奇怪。

[luckyfox]

是不是因为没有unique的索引？主键不应该就是吗

[Lucien]

麻烦发一下具体的 SQL 以及表的 schema 。

[luckyfox]

SQL
select count(1) from app_mes_smt_pcba_mat_trace_new
索引情况：

[Lucien]

原因： 执行计划统计信息不准，因为包含 stats:pseudo 解决办法： 通过 analyze table 重新收集统计信息，确认 PK 统计信息和 table column 统计信息是最新的，然后再试一下。

[luckyfox]

@SUN-PingCAP

通过 analyze table 重新收集统计信息，确认 PK 统计信息和 table column 统计信息是最新的，然后再试一下。

好的，感谢！！

[张鱼小丸子-PingCAP (zhangyuxiaowanzi)]

如果觉得别人的回答有帮助，可以将其标记为解决方案✅，这样可以帮助其他有同样问题的人快速找到答案～

[luckyfox]

好的，我在验证，OK了我来标记。谢谢提醒！

[张鱼小丸子-PingCAP (zhangyuxiaowanzi)]

[maiyang (mai)]

什么情况下出现统计信息不准确呢？ 以后怎么避免出现此类问题？

analyze table 几十亿条数据会要多长时间？会锁表吗？

[luckyfox]

谢谢！但我最后发现有统计信息正确后，速度也快不了多少。估计这个本身就需要这么时间。但统计信息确实已经不准了，现在已经恢复。

[善若水]

@luckyfox

谢谢！但我最后发现有统计信息正确后，速度也快不了多少。估计这个本身就需要这么时间。但统计信息确实已经不准了，现在已经恢复

这个有效果了嘛？

[francis0407 (Mingcong Han (PingCAP))]

这个在 2.1 版本确实没有走索引，在最新的 3.x 和 master 都可以走索引了，如果想在 2.1 版本走索引的话可能需要手动选取索引。 select count(1) from app_mes_smt_pcba_mat_trace_new use index(idx_pcb_id); 选最短的索引，可以略微提高查询的速度。

[luckyfox]

统计信息一定要准，不准会慢太多的

[luckyfox]

感谢感谢！节后打算升3.x