直接用 COUNT(*) 查全表行数在数据量大时会非常慢，尤其没合适索引或表锁竞争高时。优化核心是：避免扫全表、减少锁等待、用更轻量的统计方式替代实时精确计数。
优先使用覆盖索引 + COUNT(索引列)
当查询条件能命中索引时，MySQL 可只扫描索引树（B+Tree），不回表查数据行。若索引列非 NULL，COUNT(索引列) 和 COUNT(*) 结果一致，但性能显著提升。
例如用户表有联合索引 (status, created_at)，要查“启用状态”的用户数：
SELECT COUNT(*) FROM users WHERE status = 1;
只要 status 在索引最左前缀，且该索引包含足够筛选性，就能避免全表扫描。
立即学习“PHP免费学习笔记（深入）”；
市场营销SEO优化服务公司网站模板
下载
市场营销SEO优化服务公司网站模板是一款提供市场调查、SEO优化、策略咨询、公关和营销等商务咨询服务公司网站模板下载。提示：本模板调用到谷歌字体库，可能会出现页面打开比较缓慢。
⚠️ 注意：不要写 COUNT(id) 除非 id 是主键且确定非空；若字段允许 NULL，COUNT(字段) 会跳过 NULL 值，结果可能少于真实行数。
高频统计场景改用缓存计数
对“总用户数”“某类商品总数”等变化不频繁但查询频繁的指标，不建议每次走数据库 COUNT。
- 在增删操作时，用事务同步更新 Redis 中的计数器（如
INCR user:total/DECR user:total） - 首次加载或缓存失效时，再执行一次精确 COUNT 并重置缓存
- 可加简单校验机制（如每小时后台任务比对缓存值与 DB 实际值偏差）
这样把 O(n) 查询降为 O(1) 内存读取，响应稳定，也减轻数据库压力。
大数据量分页计数用估算或游标替代
分页列表常附带“共 XX 条”，但 SELECT COUNT(*) FROM ... LIMIT ... OFFSET ... 在偏移量很大时仍需扫描前面所有行。
- 对百万级以上表，考虑用
EXPLAIN查看预估行数：EXPLAIN SELECT * FROM orders WHERE paid = 1;中的rows字段可作粗略参考（不一定精准，但够用） - 更优解是放弃传统
OFFSET分页，改用基于主键/时间戳的游标分页（如WHERE id > ? ORDER BY id LIMIT 20），不依赖总条数也能实现无限滚动 - 如必须显示准确总数，可限制最大可查页码（如只允许查前 100 页），超限时返回“数据过多，建议搜索”
定期维护统计信息与索引
MySQL 的查询优化器依赖表的统计信息做执行计划决策。若长期未 ANALYZE TABLE，可能导致本该走索引的 COUNT 被误判为全表扫描更优。
- 对变动频繁的大表，可定时执行
ANALYZE TABLE table_name;（低峰期） - 检查是否有多余或重复索引，冗余索引会拖慢 INSERT/UPDATE，间接影响 COUNT 性能
- 对只读历史归档表，考虑使用
myisampack或转为ARCHIVE引擎（仅支持 INSERT/SELECT，COUNT 极快）
