MySQL 查询优化（七）：MySQL 的 COUNT(*) 真的如此低效？

揭开 MySQL 中 COUNT(*) 的神秘面纱：是高效还是低效？

引言

在 MySQL 查询优化的殿堂里，"COUNT() 低效" 这条定律堪称经久不衰，跻身于最易令人产生误解的话题前十榜单。为了廓清迷雾，我们不妨拨开层层迷障，一探究竟，揭开 COUNT() 的真实面目。

揭开 COUNT(*) 的面纱

COUNT() 作为一个神秘的函数，常常让人望而生畏。它的使命是统计查询结果集中记录的行数，看似简单，实则不然。为了精准地完成这项任务，COUNT() 会逐行扫描表中所有记录，逐个计数，可谓兢兢业业，一丝不苟。

低效之说缘何而起？

尽管 COUNT(*) 尽心尽力，但它有时却背负着"低效"的恶名。究其原因，主要在于以下两方面：

• 全表扫描： COUNT(*) 要求遍历整个表，逐行计数，当表中记录数量庞大时，这个过程势必耗时费力。
• 索引失效： COUNT(*) 通常无法利用索引进行优化，因为它的计数过程并不依赖于特定的字段值。

优化 COUNT(*) 的妙招

既然 COUNT(*) 存在低效的风险，那么我们该如何优化它呢？以下几个妙招值得一试：

• 使用覆盖索引： 对于只需要统计特定字段值的查询，可以通过创建覆盖索引来优化 COUNT(*)。覆盖索引将所需数据存储在索引中，从而避免了全表扫描。

CREATE INDEX idx_column_name ON table_name (column_name);

• 利用分区表： 对于大型表，可以将其分区，然后针对特定分区执行 COUNT(*) 操作。分区表将表拆分为更小的部分，从而减少了单次查询处理的数据量。

CREATE TABLE table_name (
  id INT NOT NULL,
  column_name VARCHAR(255) NOT NULL
) PARTITION BY HASH(id) PARTITIONS 4;

• 考虑近似值： 对于不需要精确计数的场景，可以使用近似值函数，如 COUNT(DISTINCT) 或 APPROX_COUNT_DISTINCT，它们可以在牺牲一定准确性的前提下提高查询速度。

SELECT COUNT(DISTINCT column_name) FROM table_name;

• 优化子查询： 如果 COUNT(*) 嵌套在子查询中，可以通过将子查询重写为连接或使用 EXISTS 操作符来优化。

SELECT * FROM table_name
WHERE EXISTS (
  SELECT 1
  FROM subquery_table_name
  WHERE subquery_column_name = table_column_name
);

适时使用 COUNT(*)

COUNT(*) 虽然存在低效的可能，但它并非一无是处。在某些场景下，它仍然是统计记录数的最佳选择，例如：

• 需要精确的记录数，无法使用近似值。
• 表中记录数量较少，全表扫描开销可忽略不计。
• 查询需要统计所有记录，无法利用索引优化。

结语

COUNT() 在 MySQL 查询优化中是一个复杂且容易被误解的话题。通过理解它的工作原理，我们可以采取适当的优化措施，规避低效的风险。在需要精确计数的场景下，COUNT() 仍然是不二之选；而在注重性能的场景下，我们则可以考虑使用其他优化策略。只有全面掌握 COUNT(*) 的特性，才能在 MySQL 查询优化中如鱼得水，挥洒自如。

常见问题解答

1. 为什么 COUNT(*) 会低效？

COUNT(*) 通常会导致全表扫描，并且无法利用索引优化，因此在表中记录数量庞大时，查询速度会受到影响。

2. 如何优化 COUNT(*) 查询？

可以考虑使用覆盖索引、分区表、近似值函数或优化子查询来优化 COUNT(*) 查询。

3. 何时应使用 COUNT(*)？

在需要精确的记录数，表中记录数量较少，或查询需要统计所有记录时，COUNT(*) 仍然是统计记录数的最佳选择。

4. COUNT(*) 和 COUNT(DISTINCT) 有什么区别？

COUNT(*) 统计表中所有记录的行数，而 COUNT(DISTINCT) 统计表中不同值的记录的行数。

5. 为什么 COUNT(*) 无法使用索引优化？

因为 COUNT(*) 不依赖于特定字段值，所以它无法利用索引进行优化。