COUNT(*)在InnoDB大表上会全表扫描，因其不维护精确行数，需遍历聚簇索引叶子节点逐行计数，即使有主键也不走覆盖索引，导致大量I/O。
为什么 COUNT(*) 在 InnoDB 大表上会全表扫描？
InnoDB 没有维护精确的行数统计，COUNT(*) 默认不走索引（哪怕有主键），而是遍历聚簇索引的 B+ 树叶子节点——本质是逐行读取记录。即使表有 1 亿行、只存 id 和 created_at，也要访问所有叶子页（可能涉及大量磁盘 I/O 或 Buffer Pool 缺页）。
- 不会使用覆盖索引优化（除非显式改写为
COUNT(id)且id是非空主键） -
WHERE条件存在时，是否走索引取决于条件选择性，但无条件的COUNT(*)几乎总触发全索引扫描 -
information_schema.TABLES.TABLE_ROWS的值只是估算，来自采样统计，误差可能达 20%～50%
用 COUNT(主键列) 能快一点吗？
不一定快，但有可能触发覆盖索引，减少数据页访问：
- 如果主键是
NOT NULL（如INT PRIMARY KEY），COUNT(id)和COUNT(*)语义等价，且优化器可能选择只扫描主键索引（避免回表） - 但如果主键是
NULLABLE（如INT PRIMARY KEY NULL），COUNT(id)必须判空，反而可能更慢 -
COUNT(1)和COUNT(*)在 MySQL 8.0+ 完全等价，优化器不做区分，不会提速
实际验证建议：
EXPLAIN SELECT COUNT(*) FROM t_large;
EXPLAIN SELECT COUNT(id) FROM t_large;对比
key 和 rows 字段是否一致。
哪些替代方案真正有效？
没有银弹，需按场景选：
- 实时精度要求低（如后台管理页显示“约 XX 万条”）：查
information_schema.TABLES，快但不准 - 需要相对准确 + 可接受秒级延迟：用近实时的汇总表，例如每 5 分钟由事件驱动任务更新
INSERT ... ON DUPLICATE KEY UPDATE count = count + delta - 写少读多、能接受轻微延迟：在业务写入路径中维护 Redis 计数器（
INCRBY/DECRBY），注意事务一致性（推荐用WATCH+ Lua 或应用层补偿） - 纯读场景且允许误差：用
SHOW TABLE STATUS LIKE 't_large'中的Rows字段（仍是估算）
不要用 SELECT COUNT(*) FROM t_large USE INDEX (PRIMARY) 强制索引——InnoDB 本来就会用主键索引，加提示无意义，还可能干扰优化器。
最容易被忽略的性能陷阱
-
AUTOCOMMIT=OFF 下执行 COUNT(*)，会持有 MVCC 读视图直到事务结束，导致 purge 线程阻塞、undo 表空间膨胀
- 带
WHERE 的 COUNT(*) 如果条件字段没索引，会先全表扫描再过滤，比无条件还慢
- 分库分表后直接
COUNT(*) 跨多个物理表，中间件（如 ShardingSphere）默认合并结果，网络和 CPU 开销陡增
- 使用
pt-table-checksum 或备份工具期间，大表 COUNT(*) 可能加剧锁竞争和复制延迟
AUTOCOMMIT=OFF 下执行 COUNT(*)，会持有 MVCC 读视图直到事务结束，导致 purge 线程阻塞、undo 表空间膨胀WHERE 的 COUNT(*) 如果条件字段没索引，会先全表扫描再过滤，比无条件还慢COUNT(*) 跨多个物理表，中间件（如 ShardingSphere）默认合并结果，网络和 CPU 开销陡增pt-table-checksum 或备份工具期间，大表 COUNT(*) 可能加剧锁竞争和复制延迟真实线上环境里，一个未加限制的 COUNT(*) 查询卡住 30 秒以上，往往不是因为“SQL 写得不够好”，而是它暴露了统计需求与存储引擎能力之间的根本错配。
