MySQL 中
COUNT()查询慢，通常不是因为函数本身，而是因为缺少合适索引、扫描了过多数据，或误用了全表扫描。优化核心是：避免全表扫描，优先走索引，减少回表和临时表。
用覆盖索引替代 COUNT(*) 或 COUNT(非主键字段)
当执行
COUNT(*)时，InnoDB 会遍历聚簇索引（即主键索引）；如果写成
COUNT(列)且该列允许为 NULL，MySQL 还需判断是否为 NULL，开销更大。若该列有非空约束（NOT NULL），优化器可能等价于
COUNT(*)，但仍建议统一用
COUNT(*)。
关键点：让查询只走二级索引（更窄、更快），而不是主键索引。例如：
表有联合索引(status, create_time)，且你常查
SELECT COUNT(*) FROM t WHERE status = 1，这个查询就能直接使用该索引的 B+ 树叶子节点完成计数，无需回表。 如果只有单列索引
status，也比全表扫描强；但注意：单独的
COUNT(*)（无 WHERE）无法利用普通二级索引，此时 InnoDB 仍会扫主键索引（不过新版 MySQL 8.0+ 对
COUNT(*)有额外优化，如采样估算或利用字典表缓存行数，但不保证精确）。
避免在大表上直接 COUNT(*) 没条件
对千万级以上表执行
SELECT COUNT(*) FROM t，本质是遍历整个聚簇索引，I/O 和 CPU 开销巨大，且会阻塞其他写操作（尤其在 RR 隔离级别下可能加间隙锁）。这不是“慢查询”，而是“不该这么查”。
实用建议：
业务上能接受近似值？可用SHOW TABLE STATUS LIKE 't'查
Rows字段（MyISAM 精确，InnoDB 是估算值，误差可能达 40%）。 需要精确值且频次不高？可异步维护一个计数表（如
table_counts），每次 INSERT/DELETE 后用事务更新对应记录。 分页场景慎用
COUNT(*)做总条数——用户翻到第 100 页时，总数早已不重要，可改用“加载更多”或游标分页（cursor-based pagination）。
WHERE 条件要走索引，别让 COUNT 变成全表扫描
COUNT(*)本身不慢，慢的是它前面的 WHERE。比如
SELECT COUNT(*) FROM user WHERE SUBSTRING(phone, 1, 3) = '138'，函数导致索引失效，必然全表扫描。
优化方向：
把计算逻辑前置：增加冗余字段（如phone_prefix），建索引并保持同步。 避免在 WHERE 中对字段做函数操作、类型隐式转换（如字符串字段与数字比较）、或使用
!=、
NOT IN、
OR等易导致索引失效的操作。 用
EXPLAIN确认
type是
ref/
range，
key显示用了哪个索引，
rows尽量小。
考虑用近似统计或采样（适合大数据分析场景）
对于超大宽表或实时性要求不高的后台报表，可启用 MySQL 的采样统计：
设置innodb_stats_method = 'nulls_unequal'或调整
innodb_stats_persistent_sample_pages提高统计准确性（影响执行计划，间接影响 COUNT 性能）。 用
SELECT COUNT(*) * 10 FROM t TABLESAMPLE SYSTEM (10)（MySQL 8.0.23+ 支持）快速估算——取 10% 样本，再放大 10 倍，误差可控且极快。 更重的方案：接入 ClickHouse 或预聚合到 OLAP 引擎，专做聚合查询。
不复杂但容易忽略：COUNT 优化的本质，是让存储引擎用最轻的方式回答“有多少行满足条件”，而不是让服务器去数每一行。
