count(*)慢因innodb需按mvcc逐行判断可见性，必须扫描聚簇索引；优化应聚焦覆盖索引、估算值（如table_rows）、redis缓存或辅助计数表，而非盲目加索引。
直接用 COUNT(*) 就慢？先看它到底在扫什么
多数人遇到慢 COUNT(*) 时第一反应是“加索引”，但 InnoDB 引擎下，COUNT(*) 默认不走二级索引，而是遍历聚簇索引（即整张表），哪怕你只查行数。原因在于：InnoDB 要按 MVCC 规则判断每行对当前事务是否可见，必须访问行记录本身。
所以不是“有没有索引”的问题，而是“能不能避开回表”——关键在覆盖扫描：
- 当
WHERE条件能命中联合索引，且该索引包含所有非 NULL 列（如(status, id)），COUNT(*)才可能仅扫描索引页，不访问数据页 -
COUNT(user_id)若user_id允许 NULL，则无法利用仅含status的索引加速，优化器会退回到全表扫描 - 用
EXPLAIN看执行计划：type是index或range，且Extra不含Using filesort或Using temporary，才算真正走覆盖
替代方案：什么时候该放弃精确值？
如果你只是想监控大盘、做分页预判、或展示“约XX万条”，COUNT(*) 的精确性反而成了性能枷锁。此时应主动降级：
-
SELECT table_rows FROM information_schema.tables返回的是采样估算值，InnoDB 下误差通常在 1%–10%，但毫秒级返回 -
EXPLAIN SELECT COUNT(*) FROM t的rows字段也是同源估算，适合单表快速探查 -
SHOW TABLE STATUS LIKE 't'同样快，且附带Data_length、Index_length，方便判断是否该优化存储 - 注意：这些值不会实时更新，
ANALYZE TABLE t可强制刷新统计，但不要在高峰期频繁执行
高频只读计数必须缓存，别靠 SQL 算
像“用户总数”“文章发布量”这类字段，查得多、改得少，每次 COUNT(*) 都是浪费。缓存不是可选项，是必选项：
- 应用层用 Redis：初始化用
SELECT COUNT(*)一次加载，后续增删用INCR/DECR；事务中务必在 DB 提交成功后再更新缓存，避免脏数据 - 数据库内建
stats表：结构为(key VARCHAR(50) PRIMARY KEY, value BIGINT, updated_at TIMESTAMP)，用INSERT ... ON DUPLICATE KEY UPDATE原子更新，适合无 Redis 环境 - 别用触发器自动维护——高并发下极易锁表；也别依赖定时任务刷——延迟不可控，且任务堆积后更难恢复
COUNT(*)、COUNT(1)、COUNT(pk) 有区别吗？
在现代 MySQL（8.0+）和 PostgreSQL 中，这三者执行计划完全一致，优化器都视作“统计行数”，不解析字段内容。但有两点容易被忽略：
-
COUNT(col)（col是普通列）语义不同：它只统计col IS NOT NULL的行，且无法利用不含该列的索引做覆盖扫描 - 如果业务真需要“非空数量”，就明确写
COUNT(status)；否则一律用COUNT(*)，语义清晰、兼容性好、优化器最熟悉 - SQL Server 等引擎对
COUNT(1)有极微小的解析开销，但实际差异远小于网络延迟，无需纠结
