InnoDB的COUNT(*)必须按ReadView逐行判断可见性并全索引扫描，本质是带过滤的快照计数；MyISAM则直接读.MYI文件头预存的rec_count元数据，时间复杂度O(1)，但不支持事务且仅无WHERE时生效。
InnoDB 的 COUNT(*) 不是“慢”，而是“必须算”；MyISAM 的 COUNT(*) 不是“快”，而是“直接读”。这不是性能调优问题，是引擎设计根本不同。
MyISAM 的 COUNT(*) 本质是读磁盘元数据
MyISAM 在 .MYI 文件头固定位置存了一个 4 字节整数，每次 INSERT/DELETE 都原子更新它。执行 SELECT COUNT(*) FROM t 时，MySQL 完全不访问数据页，只读那个偏移量的值。
- 无
WHERE条件时，时间复杂度是O(1)，10 行和 10 亿行耗时几乎一样 - 一旦加了
WHERE status = 1，MyISAM 也得走索引扫描，速度立刻掉下来 - 这个“快”有硬代价：不支持事务、崩溃后需手动修复、写操作锁整张表
- 别误以为建表没指定引擎就默认用 MyISAM——MySQL 5.7+ 默认是 InnoDB
InnoDB 的 COUNT(*) 必须按当前事务的 ReadView 逐行判断可见性
InnoDB 没有全局统一的行数，因为 MVCC 下不同事务看到的“可见行”天然不同。它只能对当前事务的 ReadView，遍历索引树、调用 row_search_mvcc 判断每行是否可见，再累加。
- 优化器会选最小的索引（比如
INDEX(status)）扫描，但仍是全索引遍历，I/O 和 CPU 开销都高 - 表越大、
buffer pool越紧张，物理读越多，超时风险越高 -
COUNT(*)、COUNT(1)、COUNT(pk)性能几乎没差别，别信“用 1 更快”的说法 -
EXPLAIN SELECT COUNT(*) FROM t显示type: index，说明确实在扫索引，不是优化器偷懒
SHOW TABLE STATUS LIKE 't' 返回的 Rows 字段不能信
这个值在 MyISAM 下是精确的，在 InnoDB 下只是采样估算（默认扫描约 10 个数据页），官方文档明确说误差可达 ±40%–50%。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 适合运维看趋势（比如发现
table_rows突降 30%，提示可能误删） - 绝不适用于分页总数、库存校验、审计统计等强一致场景
-
ANALYZE TABLE t可手动刷新估算，但会短暂锁表，别在高峰期跑
真正想让 COUNT(*) 快起来，得放弃“实时精确”
没有银弹，只有折中。InnoDB 的一致性机制决定了它没法像 MyISAM 那样存一个固定值——这不是 bug，是设计使然。
- 高频精确计数：建
counter_table，用触发器或应用层双写；注意触发器里别做复杂逻辑，否则拖慢主表写入 - 允许少量误差：缓存
COUNT(*)结果（比如 Redis），设置 5 分钟过期，配合写操作主动失效 - 查它比
COUNT(*)快得多，但你得清楚自己要的是“大概多少”还是“到底多少”
最常被忽略的一点：很多人试图靠加索引、调 innodb_stats_persistent 或换 count(1) 来“优化” COUNT(*)，结果发现毫无改善——因为问题不在 SQL 写法，而在你要求 InnoDB 做一件它设计上就不打算做的事。
