MyISAM的COUNT(*)是O(1)操作，直接读.MYI文件头rec_count元数据；InnoDB因MVCC需逐行判断事务可见性，只能全索引扫描，本质是带过滤的O(n)遍历，这是引擎设计根本差异。
COUNT(*) 在 MyISAM 下是读一个磁盘整数，在 InnoDB 下是逐行判断可见性——这不是写法问题，是存储引擎底层设计的根本分歧。
MyISAM 的 COUNT(*) 为什么快到不耗时
MyISAM 把精确行数固化在 .MYI 文件头的 rec_count 字段里，每次 INSERT 或 DELETE 都原子更新它。执行无 WHERE 条件的 COUNT(*) 时，MySQL 直接从该偏移处读取一个 4 字节整数，不访问数据页、不走索引树、不校验事务可见性。
- 时间复杂度严格是
O(1)，表从 10 行涨到 10 亿行，耗时几乎不变 - 仅对
COUNT(*)、COUNT(1)、COUNT(pk)这类无条件计数生效；一旦加WHERE status = 1，立刻退化为全表扫描 - 首次
COUNT(*)可能触发一次全表扫描（比如刚OPTIMIZE TABLE或 MySQL 启动后），但后续就稳定走元数据
InnoDB 的 COUNT(*) 为什么必须扫索引
InnoDB 支持 MVCC，不同事务的 ReadView 不同，同一时刻“可见行”天然不一致。它无法维护一个全局统一的行数，只能对当前事务上下文，调用 row_search_mvcc 逐行判断是否可见，再累加。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 优化器会选最小的二级索引（比如
INDEX idx_status (status)）来遍历，叶子节点只存索引列 + 主键，比扫聚簇索引轻 - 如果表没有二级索引，
EXPLAIN中key列显示NULL，说明只能扫主键索引（即整行），I/O 和 CPU 开销爆炸 -
COUNT(1)和COUNT(*)执行计划完全一样，都是 server 层按行计数、不取值；而COUNT(字段)若字段允许为NULL，还得取值判空，更慢
SHOW TABLE STATUS 的 Rows 字段能信吗
不能直接用于业务逻辑。它是 InnoDB 基于随机采样（默认约 10 个数据页）推算的估算值，官方文档明确说误差可达 ±40%–50%。
- 数据分布倾斜时（比如大量
DELETE后未OPTIMIZE TABLE），偏差更离谱 - 这个值不参与 MVCC 判断，也不保证事务一致性，和
COUNT(*)解决的是两类问题 - 只适合监控趋势（如发现突降 30%，提示误删）或后台报表类需求（用户看到“约 2.3 万条”就足够）
真正要解决性能问题，得绕开 COUNT(*) 本身
不是调优 SQL 写法，而是换思路：高频精确计数就别查，把“实时性”和“准确性”从查询阶段移到写入阶段。
- 用单独的计数表 +
INSERT/UPDATE/DELETE触发器，或应用层双写 - 允许少量误差：缓存
COUNT(*)结果并设 5 分钟过期，配合写操作主动失效 - 超大表只读场景：考虑分区表 + 每个分区维护局部计数，汇总时避免全表扫描
- 最常被忽略的一点：
COUNT(*)很多时候根本不需要精确值——比如“是否还有下一页”，用LIMIT 11查 11 条，够 11 条就显示“下一页”，比算总数快两个数量级
InnoDB 的 COUNT 性能瓶颈不在 SQL 写法，而在 MVCC 可见性判断这个不可绕过的环节。任何试图靠加索引、改写 COUNT(1) 来提速的尝试，都只是在边缘优化；真正卡住脖子的，是事务隔离级别下“哪一行该被数进去”这件事，必须由引擎现场决定。
