navicat执行计划中rows不准，主因是innodb统计信息过期或采样偏差；analyze table可更新估算值使其更贴近实际，但无法修复缺失索引或索引失效问题。
navicat 执行计划里的 rows 值不准，不是 sql 写错了，大概率是 mysql 的统计信息过期或不准确 —— 尤其对 innodb 表，rows 本就是估算值，差个几倍完全正常。
为什么 EXPLAIN 显示的 rows 和实际扫描行数差很多
MySQL 优化器依赖 information_schema.TABLES 中的 TABLE_ROWS 和索引统计（如 cardinality）做成本估算，而 InnoDB 不实时维护精确行数。它用采样估算，且在以下情况会严重失真：
- 大批量
INSERT/DELETE/UPDATE后未刷新统计 - 表刚从备份恢复、或使用
mysqldump导入后没触发自动分析 - 开启了
innodb_stats_persistent = OFF（默认旧版本行为），统计只存在内存中，重启即丢 - 表数据分布极不均匀（比如某字段 95% 是 NULL），采样偏差放大
ANALYZE TABLE 能解决什么，不能解决什么
这个命令强制重新采样索引和表结构，更新优化器用的统计信息。但它不改变执行计划本身，只是让估算更贴近现实 —— 比如原来 rows=100 实际扫了 50000 行，分析后可能变成 rows=48000。
- ✅ 对
WHERE条件命中索引但rows远高于实际结果集的情况，效果最明显 - ✅ 可让优化器更倾向选择覆盖索引、避免
Using filesort或临时表 - ❌ 不修复缺失索引 —— 如果
key列为空，分析完还是空 - ❌ 不解决隐式类型转换、函数包裹字段等导致索引失效的写法问题
执行 ANALYZE TABLE 的实操要点
别直接在生产库高峰期跑全库 ANALYZE，尤其大表会锁表（InnoDB 是轻量级 DML 锁，但仍有影响）。优先聚焦慢查询涉及的表：
- 先确认目标表引擎：
SHOW CREATE TABLE <code>your_table;，确保是InnoDB - 单表分析：
ANALYZE TABLE <code>your_table;（注意：不是ANALYZE单独用） - 想控制采样粒度（MySQL 5.6+）：
SET SESSION innodb_stats_sample_pages = 128;，再执行ANALYZE - 验证是否生效：查
SELECT TABLE_ROWS FROM information_schema.TABLES WHERE TABLE_NAME = '<code>your_table' AND TABLE_SCHEMA = 'your_db';，对比前后变化
比 ANALYZE TABLE 更关键的下一步
执行计划里 rows 准了，不代表查询就快了。真正卡脖子的往往是 type=ALL、key=NULL 或 Extra 里带 Using temporary。这时候得看 possible_keys 有没有候选索引却没被选中 —— 那就不是统计问题，是索引设计或查询条件匹配问题。别把 ANALYZE 当万能药，它只是让优化器“看得更清”，不是“变聪明”。
