InnoDB中COUNT(*)慢的根本原因是事务隔离与MVCC机制导致无法缓存全局行数，必须基于当前事务快照逐行扫描并判断可见性，时间复杂度为O(n)。
MySQL 执行 COUNT(*) 慢，不是 SQL 写错了，也不是服务器配置低，而是 InnoDB 引擎在事务隔离下必须逐行判断可见性——它没法“偷懒”，只能老老实实扫一遍当前快照里能看见的行。
为什么加了索引 COUNT(*) 还是慢？
很多人给 WHERE 条件列加了索引，却发现 COUNT(*) 并没变快。根本原因在于：InnoDB 的 COUNT(*) 优化器优先选“最小的二级索引”来扫描，但这个索引必须能覆盖整个过滤范围，且不能触发回表或隐式类型转换。
- 如果
WHERE create_time > '2024-01-01'上有索引，但字段类型是DATETIME，而传入的是字符串'2024-01-01'，MySQL 可能放弃走索引，退化为全表扫描 - 如果表只有主键索引、没有其他二级索引，
COUNT(*)就只能扫聚簇索引，每页读 16KB 整行数据，I/O 成倍增加 - 索引存在但统计信息过期（
ANALYZE TABLE没跑），优化器可能误判成本，选错执行路径
COUNT(*)、COUNT(1) 和 COUNT(id) 真的有性能差别吗？
在 MySQL 5.7+ 版本中，COUNT(*) 和 COUNT(1) 经过优化器处理后执行计划完全一致，性能无差异；但 COUNT(id)（id 是主键）会强制解析每行取主键值，多一次字段拷贝开销；COUNT(status)（status 允许 NULL）则需额外判断是否为 NULL，更慢。
- 业务语义明确要“所有行数”时，只用
COUNT(*)—— 它是语义最清晰、优化器最友好、实际最快的选择 - 千万别为了“看起来快”写
COUNT(1)，也别在没理解 NULL 语义时乱用COUNT(字段) - EXPLAIN 结果里看到
type: index且Extra: Using index，说明走了覆盖索引；若出现Using where; Using index，说明索引有效但仍需过滤，性能取决于匹配行数比例
不改 SQL，怎么让 COUNT(*) 快起来？
绕过 InnoDB 实时扫描的唯一办法，是把“数数”这件事从查询时移到写入时或预计算时——本质是用空间/时效性换性能。
- 高频、低精度场景（如首页展示“约 280 万用户”）：用 Redis 计数器，写操作时
INCRBY，读时直接GET；注意避免缓存雪崩，可加随机过期时间 - 中频、需一定准确性的场景（如后台运营报表）：建一张
stats_summary表，用定时任务（比如每小时）跑INSERT ... SELECT COUNT(*) FROM logs WHERE create_time >= ? AND create_time ，按天/小时聚合 - 写少读多、条件固定的场景（如
WHERE status = 'paid'）：加一个冗余字段is_paid TINYINT并建联合索引(is_paid, id)，让COUNT(*)能走极小的覆盖索引
最容易被忽略的两个坑
一个是事务长持有：如果一个事务开了很久没提交，后续所有 COUNT(*) 都得等它释放 Read View，导致可见性判断链路变长；另一个是 MVCC 清理滞后：purge 线程跟不上 delete/update 速度，undo log 积压会让每行的版本链变长，COUNT(*) 判断可见性时就得回溯更多版本。
这两个问题不会出现在 EXPLAIN 里，也不会报错，但会让同样一条 COUNT(*) 在下午突然变慢——因为上午刚 purge 过，下午 undo 堆满了。
