count()在innodb大表上慢是因为需按read view逐行判断可见性并遍历聚簇索引叶子节点，事务一致性优先于速度；mysql 8.0+中count()与count(1)执行计划完全相同，无性能差异。
为什么COUNT(*)在InnoDB大表上就是慢，不是SQL写错
因为InnoDB不存精确总行数——它得按当前事务的Read View，一行行判断可见性再计数。哪怕表只有主键、没WHERE、没JOIN，COUNT(*)也必须遍历聚簇索引叶子节点。这不是执行计划没走索引的问题，是引擎设计决定的：事务一致性优先于查询速度。你看到EXPLAIN里type=INDEX、key=PRIMARY、rows=实际行数，那已经是优化器挑过的最优路径了，再加USE INDEX提示也没用。
别信“COUNT(1)比COUNT(*)快”，8.0里它们执行计划一模一样
MySQL 8.0+优化器对COUNT(*)和COUNT(1)做了等价重写，都视作“统计所有可见行”，不会去读任何列值。实测EXPLAIN FORMAT=TREE输出完全一致，cost字段误差在±0.5%内。真正有差异的是COUNT(字段)：它必须读该字段并判NULL，哪怕字段是NOT NULL主键，优化器仍会插入非空检查逻辑，反而可能略慢。所以：
• 统计总行数，只用COUNT(*)；
• 统计某字段非空行数，才用COUNT(字段)；
• 别为“看起来更明确”写COUNT(1)，纯属冗余。
真能提速的方案，按精度和延迟分三档
没有银弹，只有取舍：
- 要秒级延迟+95%准确：用
information_schema.TABLES查TABLE_ROWS，但注意这是采样估算，千万级表误差常达20%～50%，仅适合后台管理页显示“约XX万条” - 要准到个位+可接受5秒内延迟：建一张元数据表（如
table_counts），用INSERT ... ON DUPLICATE KEY UPDATE count = count + VALUES(delta)配合业务写操作异步更新，避免触发器拖慢主流程 - 要强一致性+写少读多：用Redis维护计数器，
INCRBY/DECRBY，但必须处理事务失败回滚场景——推荐应用层补偿（如监听binlog或用本地消息表），别依赖WATCH+Lua，它在高并发下容易失败重试爆炸
最容易被忽略的坑：AUTOCOMMIT=OFF + COUNT(*) = 隐形雪崩
在长事务里执行COUNT(*)，会锁住MVCC读视图直到事务结束。这会导致purge线程卡住、undo表空间持续膨胀，其他事务的更新可能被阻塞。线上曾有案例：一个运维后台开了事务查COUNT(*)忘了提交，3小时后整个库的DML响应全超时。解决方案很简单：
• 所有COUNT(*)查询确保在自动提交模式下执行；
• 如果必须在事务中用，查完立刻COMMIT，别让它挂在那里；
• 分库分表场景下，中间件合并多个COUNT(*)结果时，网络+CPU开销会指数级上升，这时候宁可用近似值也别硬扛。
