为什么 count(*) 很慢，什么时候解释知道答案？

Question

这个查询：select count(*) from planner_event需要很长时间才能运行 - 太长了，我在它完成之前放弃并杀死了它。但是，当我运行时explain select count(*) from planner_event，我可以在输出中看到一列带有行数 (14m)。

为什么explain可以立即得到行数，而count(*)却需要很长时间才能运行？

Answer 1

解释使用以前收集的统计信息（由查询优化器使用）。做一个select count(*)读取每个数据块。

这是一种获得估计行数的廉价方法：

SELECT table_rows
FROM information_schema.tables
WHERE table_name='planner_event';

即使你做了select count(id)，它可能仍然需要很长时间，除非你有一个二级索引id（也假设id是一个 PRIMARY KEY）。因为所有数据（包括Row Data）都存储在B-Tree索引中，所以执行aselect count(PK_COLUMN)还是相当大的IO（需要读取所有数据页）。如果你在 PK 字段上有二级索引，它将能够执行更少的 IO 来执行计数。

Answer 2

解释从一些“统计数据”中获取数字，这些“统计数据”用于为优化器估计事物。这个数字可能远远不正确——我有时会发现它比准确值高或低 2 倍以上。

在 InnoDB 表上执行COUNT(*)必须扫描表以避免误算正忙于被其他连接插入/删除但尚未“提交”的记录。实际上，对某些索引进行完整扫描就足够了，不一定是整个表（包含 ）PRIMARY KEY。

你有多少内存？的价值是什么innodb_buffer_pool_size？如果这是 RAM 的 70% 左右，可能会有所帮助。