InnoDB的COUNT(*)必须扫全表，因其依赖MVCC机制，同一时刻不同事务因隔离级别和一致性视图差异导致可见行数不同，故每次需遍历聚簇索引逐行判断可见性以确保结果准确。
为什么InnoDB的COUNT(*)必须扫全表
InnoDB不存“总行数”这个值，不是它懒，而是MVCC机制决定的：同一时刻不同事务看到的行数可能不同。比如事务A刚插入一行但未提交，事务B查COUNT(*)就不能算进去；事务C在可重复读下看到的是快照，行数固定。所以每次执行COUNT(*)都得现场遍历聚簇索引，逐行判断可见性——5000万行就是5000万次判断。
别信COUNT(1)或COUNT(主键)更快的说法，它们在InnoDB里执行路径完全一样，优化器会自动等价转换，实测耗时无差别。
- MyISAM确实快，但它不支持事务、行锁和崩溃恢复，线上系统基本不用
-
SELECT table_rows FROM information_schema.tables返回的是估算值，误差可能达20%以上，不能用于精确业务统计 - 加索引对纯
COUNT(*)没用——因为没WHERE条件，优化器仍选聚簇索引扫描，二级索引反而更慢（需回表或额外排序）
什么场景该用Redis缓存计数
适合写入频次高、允许秒级延迟、容忍短暂不一致的指标，比如“文章浏览量”“当前在线用户数”。关键不是存总数，而是控制好增减原子性和失败兜底。
- 必须用
INCRBY/DECRBY，禁用GET+SET——并发下会丢数据 - MySQL写成功后，再触发Redis操作；失败则记日志，由后台任务补偿重试
- 每天凌晨用
SELECT COUNT(*) FROM t全量校准一次，结果写入SET t:count:backup，Redis宕机时可快速恢复 - 软删除逻辑里必须同步
DECRBY 1，否则计数持续虚高
强一致性要求时用元数据表
适合“会员总数”“待审核订单数”这类必须精确、且变更频率可控的统计。本质是把聚合结果物化成一行一列的普通表，靠写操作时同步更新。
- 建表语句：
CREATE TABLE t_count (name VARCHAR(64) PRIMARY KEY, cnt BIGINT NOT NULL DEFAULT 0) - 高并发写入点避免直接
UPDATE t_count SET cnt = cnt + 1——会争抢同一行锁，改用INSERT INTO t_count VALUES ('user_total', 1) ON DUPLICATE KEY UPDATE cnt = cnt + 1 - 批量导入时先算出Δ，再单条
UPDATE t_count SET cnt = cnt + ?，别循环N次UPDATE - 所有INSERT/DELETE必须配套更新，建议封装进存储过程或ORM的pre_save/post_delete钩子
带WHERE条件的COUNT(*)怎么加速
Redis和元数据表只解决全表计数，带过滤条件的查询必须回归数据库优化。核心思路是让COUNT(*)走覆盖索引，避免回表。
- 给高频过滤字段建组合索引，顺序按WHERE条件中等值字段在前、范围字段在后，例如
WHERE status = 1 AND created_at > '2024-01-01'→INDEX(status, created_at) - 确认
EXPLAIN输出中key列显示用了该索引，且Extra不含Using filesort或Using temporary - 如果条件太复杂（如多层嵌套OR、函数包裹列），考虑拆成多个
COUNT()再SUM，或用临时表预过滤 - 千万级表慎用
SELECT COUNT(*) FROM (subquery)——子查询本身可能已很慢，外层COUNT只是雪上加霜
真正麻烦的从来不是“怎么写SQL”，而是“要不要实时算”。多数业务其实只需要近似值或分钟级延迟，硬扛COUNT(*)不如提前设计好计数口径和更新时机。
