navicat 不支持直接对 update 执行 explain，仅接受以 select 开头的语句；需将 update 改写为等价 select 分析执行计划，核心是验证 where 条件的访问路径是否高效，并注意数据库版本及配置差异。
navicat 不支持直接对 update 执行 explain
点击“解释”按钮后报错或无响应，不是你语句写错了，而是 navicat 本身限制：它只接受以 select 开头的语句触发执行计划分析。对 update、insert、delete 或 ddl 语句点“解释”，navicat 会直接拒绝，返回 “no query specified” 或空白结果。
把 UPDATE 改写成等价 SELECT 再分析
执行计划的核心是访问路径（走哪个索引、扫描多少行、是否用到临时表等），这些由 WHERE 条件和涉及字段决定，与操作类型无关。所以真正要分析的是“它会查哪些行”，而不是“之后改不改”。
- 把原
UPDATE t SET a = 1 WHERE b = 2 AND c > 10拆解为：SELECT * FROM t WHERE b = 2 AND c > 10 - 确保
SELECT中的表名、字段名、条件逻辑完全一致（尤其注意别漏掉隐式类型转换或函数包裹） - 在 Navicat 中执行这个
SELECT，右键 → “解释”，看type、key、rows、Extra列是否健康 - 若
SELECT的执行计划已显示type=ALL或key=NULL，那UPDATE实际执行时必然全表扫描——优化必须从这里入手
MySQL 8.0.22+ 用户注意 optimizer_trace 配置
Navicat 图形化执行计划依赖数据库开启优化器跟踪，否则即使 SELECT 能出文本计划，也看不到右侧的可视化树状图。
- 检查连接属性 → “高级”选项卡 → 确认勾选了“使用优化器跟踪”
- 该选项底层对应 MySQL 的
optimizer_trace变量，未启用时EXPLAIN FORMAT=TREE会失败 - 如果图形计划区域始终为空白，优先排查此项，而不是反复重写 SQL
PostgreSQL 和 SQL Server 的特殊处理
不同数据库对 UPDATE 分析的支持差异更大，不能只靠改写 SELECT：
- PostgreSQL：可用
EXPLAIN ANALYZE UPDATE ...直接执行并返回真实耗时，但 Navicat 不自动补全ANALYZE—— 你得手动在语句前加EXPLAIN ANALYZE，且必须删掉末尾分号（;），否则解析失败 - SQL Server：需在连接属性 → “常规”页勾选“显示执行计划”，否则只返回文本；且图形计划仅对查询生效，UPDATE 的计划需通过 SSMS 或
SET STATISTICS XML ON获取 - Oracle：Navicat 不自动调用
DBMS_XPLAN.DISPLAY，必须手写完整流程：EXPLAIN PLAN FOR UPDATE ...; SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
实际调试时最容易忽略的，是误以为“UPDATE 有 WHERE 就一定走索引”——而执行计划只认结构匹配，不认业务意图。哪怕 WHERE 字段上有索引，只要顺序不对、用了函数、或统计信息过期，key 依然为空。
