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(*)就能解决，不必一上来就上缓存或分库分表。
