innodb的count()必须全表扫描，因其依赖mvcc一致性视图，无法预存确定行数，每次需遍历聚簇索引并逐行判断可见性；优化器虽倾向选最小索引，但无where时未必生效；count(1)与count(主键)性能等同于count()；真实可行方案包括redis异步计数、元数据表维护及紧凑二级索引+非空条件欺骗优化器。
为什么InnoDB的COUNT(*)必须全表扫描
因为InnoDB不存“总行数”这个值，不是它不想存，而是MVCC机制下根本没法存一个确定的数字。同一时刻，事务A看到10000行，事务B因刚插入未提交看到10001行，事务C在可重复读快照里固定看到9999行——COUNT(*)返回什么，取决于当前事务的一致性视图。所以每次执行都得现场遍历聚簇索引，逐行判断可见性。5000万行，就是5000万次判断。
COUNT(*)会自动选最小索引，但没WHERE就可能不生效
优化器确实会优先扫描最小的二级索引（比如只含age或status的索引），因为B+树更小、IO更少。但这个逻辑有个前提：它得能安全地用该索引来代替聚簇索引计数。如果表里没有合适的二级索引，或者优化器误判成本，它仍可能回退到扫主键。实测中，加一个KEY idx_dummy (id)（哪怕只是个冗余单列索引）常能让EXPLAIN显示type: index且key指向该索引；而直接USE INDEX对无条件COUNT(*)基本无效。
别信COUNT(1)或COUNT(主键)更快
它们在InnoDB里执行路径完全一致：优化器全都会转成COUNT(*)语义处理，不取值、不判断NULL、只累加行数。实测耗时差异在毫秒级，属于噪声范围。真正影响性能的是索引结构和扫描范围，不是括号里写啥。唯一例外是COUNT(字段)且该字段允许为NULL——这时每行都要取值判断，明显更慢。
哪些方案真能落地，哪些只是幻觉
以下方案按推荐度排序：
-
允许秒级延迟的指标：用Redis +
INCRBY/DECRBY，MySQL写成功后再异步更新，失败走后台补偿；每天凌晨用SELECT COUNT(*) FROM t校准一次写入SET t:count:backup -
强一致性且变更可控：建元数据表
t_count，写操作时用INSERT ... ON DUPLICATE KEY UPDATE cnt = cnt + 1避免单行锁争抢 -
临时应急但有坑：加一个紧凑的二级索引（如
KEY idx_stub (created_at)），再强制带上WHERE created_at IS NOT NULL——这能骗过优化器走索引，但业务语义要自洽，不能凭空多出过滤条件 -
别试：
information_schema.tables.table_rows是估算值，误差常超20%；MyISAM虽快，但线上基本不可用
最易被忽略的一点：软删除场景下，DELETE变成UPDATE SET deleted=1，但Redis或元数据表若没同步DECRBY 1，计数就会持续虚高，且这种偏差不会自动修复。
