count(*)慢的根本原因是需全表扫描，优化应优先明确需求、善用索引、拆解逻辑、检查执行计划与统计信息。
COUNT(*) 慢，往往不是 COUNT 本身慢，而是它被迫“看清全部数据”才敢下结论。只要涉及全表扫描、锁竞争、大字段、无有效索引或统计信息陈旧，COUNT 就容易成为性能瓶颈。
明确需求：真要精确总数吗？
很多场景其实不需要实时精确值：
- 用户分页显示“共 XXX 条”，可改用 估算值（如 MySQL 的
SHOW TABLE STATUS中的Rows字段，虽不精确但极快） - 后台监控类统计，允许分钟级延迟，可用 异步汇总表 或定时任务更新计数器
- 高频读写场景（如点赞数），应改用 单独计数字段，增删时用
UPDATE ... SET cnt = cnt + 1，避免每次 COUNT
善用索引：让 COUNT 走索引而非聚簇
MySQL 中，COUNT(*) 和 COUNT(主键) 在有主键时通常走主键索引（B+树），比全表扫描快；但 COUNT(非空列) 若该列无索引，仍可能回表或全扫。
- 确保表有主键（InnoDB 强制要求），
COUNT(*)会优先利用主键索引的叶子节点数量估算 - 若常按某条件 COUNT（如
COUNT(*) WHERE status=1），给status建 联合索引（如(status, id)），使索引覆盖查询，避免回表 - 避免
COUNT(大字段)（如COUNT(content)），字段越小，索引越紧凑，扫描越快
拆解逻辑：用更轻量操作替代 COUNT
不是所有“数数”都得靠 COUNT 实现：
- 判断是否存在：用
EXISTS (SELECT 1 FROM ...)，找到一条即停，比COUNT(*) > 0快得多 - 分页总数已知时：首次查总数缓存，后续仅查数据页（如 LIMIT 20 OFFSET 40），不再重复 COUNT
- 分区表场景：若按时间分区，且查询限定在最近几个分区，可只 COUNT 相关分区，再求和
检查执行计划与统计信息
慢 COUNT 很多时候源于优化器误判：
- 用
EXPLAIN SELECT COUNT(*) FROM t WHERE ...看是否走了索引、是否 Using index、rows 预估是否合理 - 长期未 ANALYZE 的表，统计信息过期，可能导致优化器放弃索引而选全表扫描——定期执行
ANALYZE TABLE t - 某些版本 MySQL 对 COUNT(*) 优化较好，但对
COUNT(col)（尤其含 NULL 判断）仍需逐行检查，尽量统一用COUNT(*)
不复杂但容易忽略：先问自己“到底需不需要这个数”，再决定是缓存、拆分、换写法，还是调优索引和统计信息。
