myisam能o(1)返回count(*)因其在.myi文件头存储并原子更新精确行数，无需扫描；innodb因mvcc和事务隔离要求必须逐行判断可见性，只能全索引扫描。
MyISAM为什么能O(1)返回COUNT(*)
因为MyISAM在表的元数据（.MYI文件）里直接存了一个精确的行数计数器，每次执行 COUNT(*) 且不带 WHERE 条件时，MySQL 就跳过所有数据页，只读这个数字——根本不需要访问数据文件（.MYD），更不用扫描索引或记录。
这个计数器是怎么维护的
MyISAM 在每个 INSERT / DELETE / REPLACE 操作后，同步更新这个计数器。它不考虑事务、不支持 MVCC，所以没有“某一行对当前会话是否可见”这种问题。只要语句成功提交，计数器就+1或-1。
- INSERT 成功 → 计数器 +1
- DELETE 成功 → 计数器 -1
- TRUNCATE TABLE → 计数器重置为 0（比 DELETE 快得多，因为不走逐行逻辑）
- REPLACE 或 INSERT ... ON DUPLICATE KEY UPDATE → 视作 DELETE + INSERT，计数器净变化取决于是否真删了行
InnoDB为什么做不到这点
InnoDB 必须支持事务隔离级别和 MVCC，同一时刻不同事务看到的“有效行数”可能完全不同：
- 事务 A 插入 10 万行但未提交 → 事务 B 执行
COUNT(*)不能看到这 10 万行 - 事务 C 正在执行长事务，期间其他事务删了一批行 → C 的
COUNT(*)必须反映“快照开始时”的可见状态 - 没有全局一致的“当前总行数”，只有“对这个事务可见的行数”
所以 InnoDB 每次 COUNT(*) 都得走一遍聚簇索引，逐行判断可见性，再累加——哪怕只是查总数，也绕不开存储引擎的真实读取路径。
别被“MyISAM快”误导了
MyISAM 的 COUNT(*) 确实快，但它代价明确：
- 表锁：任何写操作都会锁整张表，高并发写场景下容易阻塞
- 崩溃恢复弱：断电或 crash 后计数器可能和实际数据不一致，需
REPAIR TABLE - 不支持事务、外键、行级锁——这些在现代业务系统里基本是刚需
- 一旦加了
WHERE条件，MyISAM 同样要全表扫描，快不起来
真正容易被忽略的是：很多人想迁移到 MyISAM 只为优化 count，却忘了自己代码里早就有 SELECT COUNT(*) FROM t WHERE status = 1 AND created_at > '2025-01-01' 这类带条件的查询——这时候 MyISAM 和 InnoDB 一样慢，而且你还丢了事务保障。
