InnoDB中COUNT(*)慢是因为必须逐行扫描聚簇索引以保证MVCC事务可见性，无法缓存行数；优化需用覆盖索引、计数表或Redis缓存，非强一致场景可用information_schema.TABLE_ROWS估算。

MySQL大表上COUNT(*)慢，不是SQL写错了，也不是服务器不够强，而是InnoDB必须逐行扫描聚簇索引才能保证MVCC下事务可见性——它没法“猜”，只能“数”。5000万行，就得扫5000万次。

为什么EXPLAIN显示type=ALL，且rows接近总行数？

这是最典型的信号：查询没走索引，退化为全表扫描。InnoDB的COUNT(*)不依赖统计缓存，也不跳过数据页，哪怕只查总数，也要访问每一行来判断该行在当前事务中是否可见。

• 即使加了WHERE status = 'paid'，如果status没索引，或索引未覆盖（比如status允许NULL），优化器仍会选全表扫描
• COUNT(id)和COUNT(*)在InnoDB里性能几乎一样——别指望换函数能提速
• 用DATE(created_at)这类函数做条件，直接让索引失效，EXPLAIN里type必为ALL

怎么用覆盖索引把COUNT(*)从分钟级压到毫秒级？

核心目标：让InnoDB只读索引页，不回表、不碰聚簇索引。只要索引本身能回答“这一行是否存在”，就不用加载整行数据。

• 对SELECT COUNT(*) FROM orders WHERE status = 'shipped'，建联合索引(status, id)（前提是id是NOT NULL主键）
• 避免用COUNT(user_id)——哪怕user_id有索引，只要它允许NULL，优化器就无法确认该索引页上的每条记录都有效，被迫回表校验
• 用EXPLAIN验证：看到type: index或range，且Extra字段不含Using filesort或Using temporary

Redis缓存计数为什么比数据库快10–100倍？

因为Redis的INCR/DECR是内存原子操作，无磁盘I/O、无MVCC开销、无锁竞争（单key下）。但缓存不是扔进去就完事，关键在更新时机和一致性兜底。

• 写操作成功后立刻INCR或DECR，不要等事务提交后再异步刷——否则并发插入可能漏计
• 缓存key必须带业务上下文，比如用户订单数用user_orders_count:12345，别用全局total_orders硬扛所有写压力
• 必须设EX 3600类过期时间，但别用固定TTL；高并发读场景建议用“滑动刷新”：每次GET后执行EXPIRE key 3600，防雪崩

什么时候可以接受TABLE_ROWS估算值？

当你要的是“大概多少”，而不是“精确多少”——比如后台监控大盘、运营日报、管理端概览页，information_schema.TABLES.TABLE_ROWS是唯一毫秒级返回的方案。

• 查法：SELECT TABLE_ROWS FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'user';
• 误差通常在1%–10%，来自InnoDB采样统计，不实时更新；ANALYZE TABLE user可手动触发重采样，但别高频执行
• 绝对不能用于支付、库存、权限校验等强一致场景——这不是优化，是绕过一致性边界

真正难的不是选哪个方案，而是判断业务能否容忍误差、缓存更新链路是否可靠、以及有没有在WHERE条件里偷偷用了函数。这些地方一错，前面所有优化都白搭。