navicat中explain的type从ref变为all，主因是mysql 8.0优化器误判索引选择性：统计信息陈旧（last_update滞后）、innodb_stats_auto_recalc对冷表不触发、cost model重估及index_merge默认启用等叠加导致；需立即analyze table并清理冗余单列索引。
explain 结果在 navicat 里看起来不同，不是 navicat 的问题，而是你连接的 mysql 实例版本行为变了——5.7 和 8.0 的优化器逻辑、统计信息格式、默认开关都不同，navicat 只是忠实地展示 explain 输出。
为什么 Navicat 里看到的 type 从 ref 变成 ALL？
这是最直观的信号：优化器误判了索引选择性。升级后 INNODB_TABLESTATS 表里的 last_update 时间没变，导致估算行数（rows）严重失真。
- 查确认：
SELECT * FROM INFORMATION_SCHEMA.INNODB_TABLESTATS WHERE TABLE_NAME = 'your_table'，看last_update是否早于升级时间 - 交叉验证：
SHOW INDEX FROM your_table查Cardinality，再对比SELECT COUNT(DISTINCT your_col) FROM your_table；差 10 倍以上基本就是统计失准 -
innodb_stats_auto_recalc=ON不是万能的——它只对单次变更超 10% 行数的表触发，冷表永远不动
为什么 ORDER BY 在 Navicat 的 EXPLAIN 里突然显示 Using filesort？
MySQL 8.0 废弃了 max_length_for_sort_data，改用统一内存排序策略。原来靠索引有序扫描的查询，现在一律走 filesort，一旦 sort_buffer_size 不够或字段太长，立刻写磁盘临时文件。
- 判断是否真走索引排序：
EXPLAIN输出中Extra列不含Using filesort才算 - 临时修复：补全复合索引，例如
WHERE a=1 ORDER BY b,c就建INDEX(a,b,c) - 别用
SELECT *加剧恶化——字段越多，filesort内存压力越大；可先试SELECT a,b,c看是否恢复
为什么 FORCE INDEX 在 Navicat 的 EXPLAIN 里失效了？
MySQL 8.0.19+ 默认开启 index_merge=on，优化器会主动把多个单列索引“合并使用”，哪怕你写了 FORCE INDEX (idx_composite)，它也可能无视并改走 idx_a,idx_b 合并路径。
- 确认方式：在
EXPLAIN FORMAT=TREE或EXPLAIN ANALYZE输出里搜using_index_merge - 临时绕过：
IGNORE INDEX (idx_a, idx_b)把它想合并的单列索引全禁掉 - 根本解法：删掉冗余单列索引——比如已有
(a,b)复合索引，就别留(a)或(b)单列索引，减少优化器的“错误联想”
Navicat 本身不干预执行计划，但容易让人误以为是工具问题。真正要盯住的是：升级后有没有跑过 ANALYZE TABLE、有没有检查 optimizer_switch 默认值变化、有没有清理掉无用的单列索引——这些才是执行计划漂移的根源。
