COUNT()在千万级表上慢主因是优化器拒绝使用二级索引，因其随机IO成本预估高于主键顺序扫描；需满足索引字段全NOT NULL、查询为COUNT()形式、统计信息最新等硬条件，否则仍全表扫描。
COUNT(*) 在千万级表上慢，不是因为没索引，而是优化器根本没选你建的索引——它宁可扫主键，也不愿走二级索引，除非你把“成本”压到它无法拒绝。
为什么加了 INDEX idx_status (status) 后 EXPLAIN 还显示 type: ALL
常见错误现象：EXPLAIN SELECT COUNT(*) FROM orders WHERE status = 'paid' 显示 key: NULL 或 type: ALL，Handler_read_next 值飙升；哪怕 status 上有索引，MySQL 仍全表扫描。
- 优化器判断二级索引页随机跳转成本 > 主键聚簇索引顺序扫描成本，尤其当
status区分度低（比如只有'paid'/'cancelled'两种值）、或该列允许为NULL、或统计信息过期时 - 必须满足硬条件：索引字段定义为
NOT NULL，且查询不含需判空的列（COUNT(*)满足，COUNT(status)不满足） - 执行
ANALYZE TABLE orders强制更新统计信息，让优化器重新评估索引成本 - 检查实际索引宽度：如果
status是VARCHAR(255)且无前缀，索引本身可能比主键还宽，优化器直接弃用
COUNT(*) 走覆盖索引的两个必要条件
不是“建了索引就能走”，而是 MySQL 只在严格满足以下两点时，才用二级索引替代主键扫描：
- 索引中所有字段均为
NOT NULL（哪怕只有一个字段允许NULL，整个索引就失效） - 查询是
COUNT(*)或COUNT(pk)形式，不能是COUNT(col)（后者必须读值判空） - 验证方式：执行
EXPLAIN SELECT COUNT(*) FROM orders WHERE status = 'paid'，看Extra字段是否含Using index - 实测对比：
COUNT(*) WHERE status = 1走idx_status（仅含 status + 主键 ID），比COUNT(status) WHERE status = 1快 20%~40%，因后者强制回表取 status 值再判空
如何构造一个优化器“不得不选”的最小索引
目标不是“有索引”，而是让这个索引成为整张表里最窄、最确定、最便宜的那个访问路径：
- 优先用窄字段组合：例如
ALTER TABLE orders ADD INDEX idx_status_id (status, id)，其中id是INT NOT NULL主键；这样索引项只存status+id，远小于主键聚簇索引的整行数据 - 避免给低基数字段单独建索引：如
is_deleted TINYINT，95% 都是0，优化器大概率判定选择性太差而弃用 - 别在大文本列（
TEXT、JSON）上建索引指望加速COUNT(*)，索引体积爆炸，反而拖慢扫描 - 如果业务常查
COUNT(*) WHERE shop_id = ? AND created_at > ?，索引必须是(shop_id, created_at)，顺序不能反——否则created_at无法用于索引过滤
什么时候该放弃 COUNT(*) 精确值
当单次 COUNT(*) 查询稳定超过 500ms，说明 IO 已成瓶颈，继续调优索引收益递减：
- 前端分页组件不显示总条数和总页数，只保留“下一页”按钮——这是最彻底的解法，无需改库
- 用
SHOW TABLE STATUS LIKE 'orders'查TABLE_ROWS字段，它是采样估算值，毫秒返回，适合容量预估、冷热判断等非精确场景 - 若必须精确值，用独立计数表：每次
INSERT/DELETE时，在同一事务里UPDATE table_row_count SET row_count = row_count + 1 WHERE table_name = 'orders'；但要注意写入并发冲突和事务开销 - Redis 缓存方案看似快，但缓存与 DB 一致性最难兜底——尤其批量导入、逻辑删除等场景，容易出现“明明删了 100 条，缓存还显示总数没变”
真正卡住性能的，往往不是 SQL 写得不够巧，而是业务没想清楚：这个总数，是不是真的每一毫秒都必须精确？
