为何MySQL中count(id)带LIMIT仍慢，distinct(id)却快？

核心差异原因 #

两个查询的执行逻辑完全不同，LIMIT的作用场景也天差地别：

• select distinct(id) from <table_name> limit 1：因为id是主键，本身具备唯一性，distinct(id)等价于直接取主键索引的第一条数据。InnoDB的主键索引是聚簇索引，查询时直接定位到索引的最顶端节点，取到第一行就返回，全程只需要极少量IO操作，所以速度极快。
• select count(id) from <table_name> LIMIT 1：count(id)的目标是统计所有非空id的行数（主键不可能为空，即统计全表总行数）。InnoDB没有MyISAM那样的总行数缓存，必须扫描整个主键聚簇索引来完成计数，LIMIT 1在这里完全不起作用——因为count的计算过程必须遍历完所有行得到总数后，才会执行LIMIT限制返回行数，本质上还是全表扫描，1500万行的扫描自然耗时很长。

排查方向 #

• 查看执行计划：用EXPLAIN分别执行两个语句，对比输出结果。count(id)的rows字段会显示接近1500万，type为index或ALL；而distinct(id) limit 1的rows为1，Extra会包含Using index, Using limit，直观看到两者的执行路径差异。
• 确认InnoDB计数特性：你的MySQL 5.7.15版本确实没有对count(id)做特殊优化，InnoDB只有在查询条件命中覆盖索引且不需要回表时，计数才会更快；主键聚簇索引包含所有行数据，扫描它和扫全表开销一致。
• 排查性能瓶颈：
  • 检查表是否存在未提交事务或锁冲突：长时间运行的事务会让InnoDB在计数时维护一致性视图，增加额外开销；用SHOW ENGINE INNODB STATUS查看锁状态。
  • 分析磁盘IO性能：1500万行的聚簇索引扫描需要大量随机/顺序IO，如果服务器磁盘性能差（比如用机械硬盘），会显著拖慢计数速度。
  • 检查主键索引碎片：用SHOW INDEX FROM <table_name>查看Cardinality是否与实际行数偏差过大，或者用OPTIMIZE TABLE <table_name>（注意锁表）整理索引碎片，减少扫描时的IO开销。
• 验证替代方案：
  • 如果不需要精确行数，用SHOW TABLE STATUS LIKE '<table_name>'获取Rows字段的估算值，速度几乎是即时的。
  • 如果需要精确行数，考虑定时任务（比如每小时）将统计结果写入单独的统计表，业务查询直接读取该表；或者创建一个仅包含非空字段的覆盖索引，扫描覆盖索引的开销远小于聚簇索引，能加快计数速度。

内容的提问来源于stack exchange，提问作者Neerav