InnoDB的COUNT(*)必须逐行验证MVCC可见性，无法预存总数，故需扫描聚集索引或最小覆盖索引以确保事务一致性。
MySQL InnoDB 中 COUNT(*) 为什么必须走聚集索引（或等效索引）
因为 InnoDB 没有全局行数计数器，且事务隔离（尤其是 RR 级别）下，不同事务看到的“可见行数”可能完全不同。COUNT(*) 不是读一个变量，而是要真实统计当前事务视角下所有满足可见性规则的行——这就绕不开逐行判断 MVCC 可见性，而判断依据必须来自某份有序、完整、能代表行存在性的物理结构。
聚集索引（主键索引）天然满足这个要求：它的叶子节点包含整行数据（或至少包含行的存在标记），且按主键顺序组织，遍历时可跳过被删除但未 purge 的记录（通过隐藏列 DB_TRX_ID 和 DB_ROLL_PTR 判断）。没有聚集索引时，InnoDB 会隐式生成一个 6 字节的 ROW_ID 聚簇索引，所以本质上仍是“扫描某个聚簇结构”。
为什么不能只查元数据或用 MyISAM 那种方式
MyISAM 表头里存了精确行数，是因为它不支持事务、无 MVCC、写操作加表锁——行数对所有会话永远一致。InnoDB 完全不具备这个前提：
-
COUNT(*)在事务 A 中执行时，事务 B 可能正插入/删除行；A 必须忽略 B 未提交的变更，也不能提前看到 B 已提交但对其不可见的变更 - 即使同一事务内两次
COUNT(*)，结果也可能不同（比如中间有其他事务提交了新行且对当前事务可见） - Server 层无法维护这种动态可见性状态，只能委托存储引擎在扫描时实时判定
MySQL 8.0 后为何有时不扫聚集索引
优化器发现存在更小的二级索引（比如单列 INDEX idx_status(status)），且该索引的叶节点大小远小于聚集索引（因不存整行），就会选择扫描它——只要能确认该索引覆盖全部行（即每行在该索引中都有一个非 NULL 条目），就能用索引行数代替表行数。
但注意几个关键限制：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 该二级索引必须是非空列（否则
NULL值不入索引，会漏计） - 如果
WHERE条件涉及该索引列，优化器可能放弃此优化（避免重复过滤逻辑） -
EXPLAIN中type显示为index、key显示具体索引名、Extra含Using index，才是真走了覆盖索引扫描
实际影响：什么时候你会明显感知到慢
当表无任何有效索引（包括主键）、或聚集索引极大（比如主键是长字符串+大量大字段）、或二级索引也很大时，COUNT(*) 就退化为实质上的全表扫描——不只是读索引页，还可能触发回表（若优化器误判）或大量 IO 等待。
典型高危场景：
- 分库分表后单表仍达千万级，但没建主键或主键设计不合理（如 UUID）
- 历史归档表被
ALTER TABLE ... DROP PRIMARY KEY后又忘了重建 - 使用
COUNT(*)做分页总数（SELECT COUNT(*) FROM t WHERE x=1），而x列无索引
最常被忽略的一点：哪怕加了索引，如果查询条件和索引无法配合（例如 WHERE status IN (1,2) AND created_at > '2025-01-01'，但只对 status 建了单列索引），优化器仍可能放弃索引扫描 COUNT(*)，回落到聚集索引甚至全表扫描。
