navicat中rows值暴涨八成是统计信息过期所致；innodb的table_rows和cardinality非实时更新，大批量写入后需手动analyze table刷新，但若type=all或key=null，则属索引缺失或查询问题。

Navicat里看到的rows值突然暴涨，八成是统计信息过期了

Navicat执行计划中rows列数值跳变（比如从几百飙到几十万），但SQL本身没改、数据量也没突增，大概率不是查询写错了，而是MySQL优化器“看走眼”了——它依赖的统计信息陈旧或采样失真。InnoDB的TABLE_ROWS和索引cardinality不是实时更新的，大批量写入后不主动刷新，估算就会严重偏离实际。

怎么确认是不是统计信息问题

别猜，直接查系统表比对：

navicatmysql

Navicat For MySQL

下载

• 运行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。这些才是索引设计或查询写法的问题，统计信息只是帮你看清瓶颈在哪