COUNT(*)在千万级InnoDB表上慢是因为必须扫描主键索引以保证MVCC可见性，而非写法问题；优化方向是缓存精确值（计数表/Redis）或采用元数据估算（information_schema.TABLE_ROWS）。
COUNT(*) 在千万级 InnoDB 表上慢，不是因为写法不对，而是它真要扫完主键索引——哪怕你只想要一个数字，MySQL 也得把几千万行主键值从磁盘或缓冲池里过一遍。优化方向很明确：别让它算，提前存好，或换种方式“不精确但够用”。
为什么 COUNT(*) 走索引也慢？
InnoDB 的 COUNT(*) 默认走聚簇索引（也就是主键索引），哪怕你建了二级索引，优化器通常也不选——因为它要的是“总行数”，而二级索引可能包含 NULL 或被标记为删除的记录（MVCC 可见性判断必须落到聚簇索引上）。
常见错误现象：EXPLAIN 显示 type: index、rows 接近表总行数、Extra 为空，说明它确实在扫整个主键索引。
别信“COUNT(1) 比 COUNT(*) 快”——InnoDB 下二者执行路径完全一致，无性能差异。
主键越宽（比如用 UUID），扫描成本越高；主键是自增 BIGINT 已经算友好。
用 information_schema.TABLE_ROWS 快但不准
这是最轻量的“绕开计算”方式，直接读 InnoDB 的元数据估算值：SELECT TABLE_ROWS FROM information_schema.tables WHERE table_name = 'orders' AND table_schema = 'mydb';
它快（毫秒级），但误差常达 10%–50%，且不反映实时增删——尤其在高并发写入后，数值可能滞后数分钟甚至更久。
适用场景：后台看板显示“约 1200 万订单”，前端 loading 动画旁写“正在加载约 XX 条数据”。
不能加 WHERE 条件；不能用于事务一致性要求高的逻辑（比如库存校验前先查“还有多少未发货订单”）。
建计数表做强一致更新
适合“必须精确、允许写开销”的场景，比如会员总数、待审核工单数。
建表极简：CREATE TABLE order_count (name VARCHAR(32) PRIMARY KEY, cnt BIGINT NOT NULL DEFAULT 0); INSERT INTO order_count VALUES ('total', 0);
所有写操作必须配套更新：
• 插入新订单：用 INSERT INTO order_count VALUES ('total', 1) ON DUPLICATE KEY UPDATE cnt = cnt + 1，避免 UPDATE ... SET cnt = cnt + 1 引发行锁争用
• 删除订单：同样 ON DUPLICATE KEY UPDATE cnt = cnt - 1，或显式 UPDATE 配事务
• 批量导入：先 SELECT COUNT(*) FROM temp_import 算出 Δ，再单条 UPDATE order_count SET cnt = cnt + ? WHERE name = 'total'，别循环执行
注意：触发器看似自动，但在主从复制或批量 DML 下易丢更新，推荐在应用层或存储过程中统一封装。
用 Redis 做秒级最终一致计数
适合“写多读少、容忍短暂误差”的场景，比如文章阅读量、实时在线人数。
关键不是存值，而是控制增减时机：
• 必须先成功写 MySQL，再执行 INCRBY；失败则落日志，由补偿任务重试
• 绝对不用 GET + SET 模拟原子操作——并发下必丢数据
• 每日凌晨用 SELECT COUNT(*) FROM t 全量校准一次，写入 SET t:count:backup 作为兜底
• 软删除逻辑里记得同步 DECRBY 1；硬删除一般已含该动作
风险点：Redis 宕机期间计数停滞，但有校准机制兜底；若业务要求“任何时刻都不可错”，就别选这条路。
真实场景中，最容易被忽略的是条件统计——比如 COUNT(*) WHERE status = 1 AND created_at > '2024-01-01'。Redis 和计数表都帮不上忙，此时唯一靠谱的做法是给 (status, created_at) 建联合索引，并确认执行计划中出现 Using index（覆盖索引扫描），否则仍会回表或全扫。
