MySQL中COUNT()变慢的根本原因是InnoDB在MVCC下需逐行判断可见性，无法直接读取行数，全表扫描是常态；COUNT()、COUNT(1)、COUNT(id)性能几乎相同，因优化器均执行全聚簇索引扫描。
MySQL 中 COUNT(*) 变慢，根本不是写法问题，而是 InnoDB 引擎必须在 MVCC 下对每一行做可见性判断——它没法“直接读个数”，只能老老实实扫数据。千万级表上跑一次全表 COUNT(*)，耗时几秒到几十秒，是常态，不是 bug。
为什么 COUNT(*)、COUNT(1)、COUNT(id) 执行时间几乎一样
因为优化器在 InnoDB 下对这三者基本不做区分：只要没 WHERE 条件或条件无法走索引，最终执行计划都是 type=ALL 或 type=index（全聚簇索引扫描）。扫描的是主键 B+ 树的全部叶子节点，每页加载、每行判断可见性、再累加，I/O 和 CPU 开销都来自这里，跟括号里写啥无关。
常见错误现象：
- 看到
EXPLAIN显示key=PRIMARY就以为“走了索引很高效”，其实type=index仍是全索引扫描，和全表扫代价接近 - 给
status字段单独建了索引，但COUNT(*) WHERE status = 1还是慢——因为没覆盖，仍需回表或判断可见性 - 误以为
COUNT(id)比COUNT(*)快，实测差异在毫秒级，无业务意义
带 WHERE 条件的 COUNT(*) 怎么才能快起来
核心目标：让执行计划从 ALL 或 index 降为 range 或 ref，且尽可能走覆盖索引（避免回表 + 减少页加载）。
- 高频过滤字段必须组合建索引，例如
WHERE status = 1 AND created_at > '2024-01-01'，应建INDEX(status, created_at)，而非两个单列索引 - 如果查询只统计数量、不查其他字段，把所有 WHERE 字段都放进联合索引，就能触发覆盖索引扫描，此时
Extra = Using index是关键信号 - 注意字段顺序：等值条件（
=）放前面，范围条件（>、BETWEEN）放后面；status = 1是等值，created_at > ...是范围，所以索引顺序必须是(status, created_at) - 不要依赖
OR条件走索引——它大概率触发全表扫描；改用UNION ALL拆解并分别走索引
千万级表真要精确总数，别硬扫，换思路
硬扛 COUNT(*) 是自找麻烦。线上系统真正需要的，往往不是“此刻精确总数”，而是“低延迟、可接受误差、强一致性可选”的方案。
- 纯读多写少场景（如文章浏览量），用 Redis
INCRBY：每次 INSERT 后同步 +1，DELETE 后 -1；注意必须应用层双写 + 失败补偿，不能靠 GET+SET - 要求强一致（如会员总人数），建元数据表
t_count(name VARCHAR, cnt BIGINT)，所有 DML 都配套INSERT ... ON DUPLICATE KEY UPDATE cnt = cnt + 1，避免行锁争用 - 允许 5% 以内误差，直接看
SHOW TABLE STATUS LIKE 'orders'的Rows字段，或EXPLAIN SELECT COUNT(*) FROM orders的rows估算值——快，但不准，且不支持 WHERE - 定时任务每小时跑一次精确
COUNT(*)写入汇总表，前台查这个表；适合后台报表类需求，非实时但稳定
最易被忽略的一点：没有 WHERE 的 COUNT(*) 在 InnoDB 里永远不可能 O(1)。所谓“秒级”，本质是绕过它——要么换存储（MyISAM 不现实），要么换介质（Redis/汇总表），要么换精度（估算）。想靠调优一条 SQL 让千万级 COUNT(*) 从 10 秒压到 100ms？不存在的。
