COUNT(*)在大表上慢是因为InnoDB需实时全表扫描，无缓存；status无索引或COUNT(status)含NULL判断会加剧性能问题；建覆盖索引如INDEX(status, id)可优化，但需权衡写入开销与事务可见性影响。
为什么 COUNT(*) 在大表上慢得像卡住
MySQL 的 COUNT(*) 看似简单，但实际执行时可能扫全表——尤其当没有合适索引、或查询涉及 WHERE 条件且字段没索引时。InnoDB 不像 MyISAM 那样缓存行数，每次都要实时统计；更糟的是，如果查询走不了索引，就会触发聚簇索引（主键）的全扫描，IO 和 CPU 压力陡增。
- 表有 2000 万行，
COUNT(*) WHERE status = 1耗时 8 秒 → 很可能status没索引，或索引未被选中 -
EXPLAIN显示type: ALL或rows接近总行数 → 就是全表扫描了 - 即使加了
INDEX(status)，COUNT(*)仍可能不走它 → 因为二级索引不存整行，InnoDB 还得回表查主键（而 COUNT 不需要数据，纯属浪费）
COUNT(主键) 和 COUNT(*) 其实没区别，但 COUNT(字段) 很危险
COUNT(*) 和 COUNT(id)（假设 id 是主键且非空）在 InnoDB 下执行计划通常一致，优化器知道主键必非空，会直接走主键索引统计。但一旦写成 COUNT(status)，语义就变了：它只统计 status IS NOT NULL 的行，优化器无法跳过 NULL 判断，大概率放弃索引，改走聚簇索引逐行判断。
-
COUNT(*)→ 统计所有行，优化器可选任意非空索引（包括二级索引） -
COUNT(id)（主键）→ 等价于COUNT(*)，安全 -
COUNT(status)→ 必须检查每行status是否为 NULL，即使有INDEX(status)，也可能因 NULL 处理开销被迫全扫
所以，别为了“看起来明确”写 COUNT(status)，真要过滤再统计，用 COUNT(*) WHERE status IS NOT NULL 更可控。
覆盖索引怎么建才让 COUNT 快起来
覆盖索引的核心是：让 MySQL 仅靠索引本身就能完成统计，不用回表、不读聚簇索引。对 COUNT(*) WHERE status = 1 这类查询，最直接的方式是建一个「单字段 + 非空约束」的二级索引，并确保条件列是索引最左前缀。
- 建索引：
ALTER TABLE orders ADD INDEX idx_status (status) - 如果
status允许 NULL，加个WHERE status IS NOT NULL条件反而能帮优化器选索引 - 更稳妥的做法：把常用过滤字段和主键组合建联合索引，例如
INDEX(status, id)→status过滤，id保证非空，索引本身就“覆盖”了统计所需全部信息 - 注意：不要建
INDEX(status, created_at)这种冗余索引去跑COUNT(*)，多出的字段不参与统计，还拖慢索引维护
验证是否生效：用 EXPLAIN SELECT COUNT(*) FROM orders WHERE status = 1，看 key 是否命中你建的索引，且 rows 显著小于总行数。
聚合统计快了，但业务逻辑可能悄悄出错
覆盖索引加速的是“纯统计”，但它不改变事务可见性。比如在 RR 隔离级别下，一个长事务未提交，COUNT(*) 仍会看到它已插入但未提交的行（因为 MVCC 快照包含该事务的修改）。这通常合理，但如果你在做实时监控大盘，误以为“当前活跃订单数”已落库，其实只是未提交脏数据，就会误导决策。
-
COUNT(*)结果反映的是当前事务快照下的行数，不是“已提交总数” - 想逼近已提交状态？代价很大：加
SELECT ... FOR UPDATE或切到 RC 级别，但会牺牲一致性 - 更现实的做法：接受这个语义，把统计口径写进监控文档，比如注明“含未提交事务可见行”
真正容易被忽略的，是索引维护成本。给大表加 INDEX(status, id) 可能让写入变慢 5%～10%，尤其在高频 INSERT 场景。上线前务必在从库或影子表压测，别只看 COUNT 快了就拍板。
