MySQL 中 count 查询慢的根源在于未理解其执行逻辑，优化需避免全表扫描、减少锁竞争、绕过行级计算；count(*)统计行数可走最小索引或计数缓存，而 count(字段）须逐行判 NULL，性能更差。
MySQL 中 count 查询慢，通常不是因为 SQL 写得不对，而是没理解 count 的执行逻辑和底层机制。优化核心在于：避免全表扫描、减少锁竞争、绕过不必要的行级计算。
明确 count(*)和 count(字段）的本质 区别
count(*)统计的是行数，InnoDB 会优先走最小的二级索引（如主键）或专门的“计数缓存”（如某些版本的 information_schema.PARTITIONS）；而 count(字段）必须逐行判断该字段是否为 NULL，无法跳过 NULL 值，强制走聚簇索引或全表扫描。
- 能用 count(*)就别用 count(id)或 count(1)，除非业务强依赖非空字段校验
- 避免 count(非索引字段），比如 count(email)，尤其当 email 允许 NULL 时，性能损耗明显
- 如果字段有 NOT NULL 约束且已建索引，count(字段）可能走该索引，但依然不如 count(*)稳定
大表 count(*)不加条件时的替代方案
对上亿行的表执行 select count(*) from t，即使走了主键索引，仍需遍历全部叶子节点，耗时高、易阻塞其他 DML。
- 用 show table status like ‘t’ 查看 Rows 字段（近似值，误差一般
- 维护一个计数表，如 counter(table_name, row_count)，配合 INSERT/DELETE 触发器或应用层增减（注意并发更新需加行锁或乐观锁）
- 对分区表，可汇总 information_schema.PARTITIONS 中各分区的 TABLE_ROWS 相加（同样为估算值）
带 WHERE 条件的 count 优化关键点
带条件的 count 本质是“带过滤的扫描”，性能取决于能否命中有效索引及索引覆盖程度。
- 确保 WHERE 字段有高效索引，且选择性高（例如 status= 1 比 type=’user’ 更易走索引）
- 尽量让索引覆盖查询路径，例如 select count(*) from t where status=1 and create_time > ‘2024-01-01’，应在 (status, create_time) 上建联合索引
- 避免在 WHERE 中对字段做函数操作，如 count(*) where DATE(create_time) = ‘2024-01-01’，会导致索引失效
利用近似统计快速响应（适合实时性要求不高场景）
MySQL 8.0+ 支持采样统计，也可借助外部 工具 降低精度换速度。
- 使用 explain 分析执行计划，确认是否 Using index；若显示 Using where，说明回表严重，需优化索引
- 对超大表，可考虑用 SELECT SUM(TABLE_ROWS) FROM information_schema.PARTITIONS WHERE TABLE_SCHEMA=’db’ AND TABLE_NAME=’t’（仅适用分区表）
- 业务允许误差时，用 SELECT COUNT(*) * 10 FROM t TABLESAMPLE SYSTEM (10) —— MySQL 8.0.19+ 支持的系统采样语法
不复杂但容易忽略：很多慢 count 问题，其实一条合适的联合索引 + 改用 count(*)就能解决，不必一上来就上缓存或分库分表。
