MyISAM的COUNT(*)快是因为直接读取.MYI文件头中持久化的rec_count元数据，时间复杂度O(1)，无需扫描数据；但代价是不支持事务、崩溃恢复和行级锁，仅适用于读多写少的非ACID场景。
MyISAM 的 COUNT(*) 为什么快到几乎不耗时？
因为它根本没扫描数据——COUNT(*) 直接从磁盘元数据里读一个整数。MyISAM 在表结构文件（.MYI）中持久化维护了精确行数，不管表有多大，只要没 WHERE 条件，就是 O(1) 查询。
但这背后代价明确：不支持事务、无崩溃恢复、写操作会锁整张表。所以它只适合日志归档、报表快照这类读多写少且不要求 ACID 的场景。
InnoDB 的 COUNT(*) 为什么必须逐行判断？
核心卡点是 MVCC —— 同一时刻，不同事务的 ReadView 不同，看到的“可见行”数量天然不一致。InnoDB 无法存一个全局统一的行数，只能对当前事务上下文，一行行取出、判断可见性、再累加。
实际执行时，优化器会选最小的索引树遍历（比如只有 INT 字段的二级索引），但仍是全索引扫描。如果表没二级索引，就只能扫主键索引（叶子节点存整行），I/O 和 CPU 开销更大。
-
COUNT(*)和COUNT(1)性能几乎一样，都是 server 层按行计数，不取值 -
COUNT(id)要从行里解析出主键字段，有额外拷贝开销 -
COUNT(字段)若字段允许为NULL，还得取值再判空，最慢
SHOW TABLE STATUS 返回的 Rows 字段能信吗？
不能直接用。它是基于采样的估算值，InnoDB 通过随机选取几个页、统计平均行密度来推算总数，官方文档明确说误差可能达 40%–50%。尤其在数据分布倾斜（比如大量删除后未 OPTIMIZE TABLE）时，偏差更离谱。
它适合快速探查量级（百万级？千万级？），但绝不能用于分页总数、库存校验、审计统计等需要精确结果的逻辑。
真正要解决性能问题，得绕开 COUNT(*) 本身
不是调优 SQL 写法，而是换思路：
- 高频精确计数：用单独的计数表 +
INSERT/UPDATE/DELETE触发器或应用层双写，把“实时性”和“准确性”从查询阶段移到写入阶段 - 允许少量误差：缓存
COUNT(*)结果并设置合理过期时间（比如 5 分钟），配合写操作主动失效 - 超大表只读场景：考虑分区表 + 每个分区维护局部计数，汇总时避免全表扫描
最常被忽略的一点：很多接口里的 COUNT(*) 其实根本不需要精确值——比如“是否还有下一页”，用 LIMIT 11 查 11 条，够 11 条就显示“下一页”，比算总数快两个数量级。
