Navicat中rows值暴涨八成是统计信息过期所致；InnoDB的TABLE_ROWS和cardinality非实时更新，大批量写入后需手动ANALYZE TABLE刷新，但若type=ALL或key=NULL，则属索引缺失或查询问题。
Navicat里看到的rows值突然暴涨，八成是统计信息过期了
Navicat执行计划中rows列数值跳变（比如从几百飙到几十万），但SQL本身没改、数据量也没突增，大概率不是查询写错了，而是MySQL优化器“看走眼”了——它依赖的统计信息陈旧或采样失真。InnoDB的TABLE_ROWS和索引cardinality不是实时更新的，大批量写入后不主动刷新，估算就会严重偏离实际。
怎么确认是不是统计信息问题
别猜，直接查系统表比对：
- 运行
SELECT TABLE_NAME, TABLE_ROWS, UPDATE_TIME FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table';，看UPDATE_TIME是否明显滞后于最近一次大更新时间 - 检查
innodb_stats_persistent是否为OFF（旧版本默认）：若为OFF，重启MySQL后统计全丢，必然不准 - 对比
EXPLAIN里的rows和实际返回行数：如果偏差持续超过5倍，且type仍是ref或range（说明索引在用），基本可锁定统计问题
ANALYZE TABLE不是万能药，但必须先做这一步
ANALYZE TABLE能强制重采样，让rows估算更贴近现实，但它不解决根本设计缺陷：
- ✅ 对
WHERE条件命中索引但rows虚高、Extra出现Using filesort或Using temporary的情况，效果最直接 - ❌ 如果
key列为空、type是ALL，说明索引根本没被选中——这时ANALYZE再勤快也救不了，得检查隐式转换、函数包裹字段或缺失索引 - ⚠️ 大表执行
ANALYZE TABLE会加轻量DML锁，生产环境避开高峰期；优先只跑慢查询涉及的几张表，别全库扫
Navicat里容易忽略的关键验证点
很多人点了“解释”按钮就以为完事了，但以下三点不核对，等于白看：
- 确保当前标签页显示的是目标语句的执行计划——Navicat不保存历史计划，关掉就丢，导出前务必确认
- 导出CSV时文件名带上时间戳和表名，比如
20260907_orders_analyze_before.csv，否则几天后你分不清哪份是分析前哪份是分析后 -
rows准了不代表查询快了：真正卡脖子的是type=ALL、key=NULL、Extra里带Using temporary。这些才是索引设计或查询写法的问题，统计信息只是帮你看清瓶颈在哪
