SQL批量更新时查看详细执行计划的方法

说到在Oracle里预览一条UPDATE的执行计划，很多人的第一反应就是使用EXPLAIN PLAN FOR。没错，这确实是最稳妥的试探方式——语句仅作解析、不实际执行，因此不会真正修改数据。但需要注意的是：运行完EXPLAIN PLAN FOR之后，还得手动执行一句SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);才能看到输出结果。如果语句中带有绑定变量（比如:1），解析计划本身没有问题，但变量值对选择率的影响就无法体现出来。此外，即使只是解析不执行，复杂语句的硬解析仍可能在内存中争夺shared pool latch，因此生产环境还是需要谨慎考虑。

Oracle中通过EXPLAIN PLAN FOR查看UPDATE执行计划

直接给UPDATE语句加上EXPLAIN PLAN FOR是可行的，但要注意它只做解析、不执行，所以不会实际修改数据。这是最安全的预览方式。

• EXPLAIN PLAN FOR UPDATE sys.job SET this_date = :1 WHERE job = :2; 执行后不会改动任何行，仅生成执行计划
• 紧接着必须执行 SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY); 才能看到输出结果
• 如果语句包含绑定变量（如:1），EXPLAIN PLAN FOR仍能正常解析访问路径，但无法反映变量值对选择率的影响
• 避免在生产环境对大表直接执行EXPLAIN PLAN FOR——虽然不执行DML，但复杂语句的硬解析可能争夺shared pool latch

SQL Server中按Ctrl+L或使用SET SHOWPLAN_XML ON

SQL Server的图形化执行计划更直观，但批量更新（比如UPDATE TOP (1000) ...）的计划容易被误读：它默认展示的是“估计计划”，而非真实执行时的计划。

• 快捷键Ctrl+L仅生成估计计划；要看到实际运行时的计划，需要先开启SET STATISTICS XML ON再执行UPDATE
• SET SHOWPLAN_XML ON会阻止语句执行，适合验证逻辑；而SET STATISTICS XML ON会实际执行并返回XML格式的真实计划
• 批量更新若带有TOP或WHERE条件，注意观察是否出现Clustered Index Seek还是Table Scan——前者通常更快，但前提是索引覆盖了过滤列和更新列
• 如果执行计划中频繁出现Key Lookup，说明非聚集索引没有包含所有被更新的字段，会导致额外的I/O开销

MySQL使用EXPLAIN FORMAT=JSON查询UPDATE计划（5.7+）

MySQL原生EXPLAIN不支持UPDATE语句，直接写EXPLAIN UPDATE ...会报错ERROR 1064。必须转换思路。

• 将UPDATE改写为等价的SELECT，例如UPDATE orders SET status='shipped' WHERE user_id=123 → 对应EXPLAIN FORMAT=JSON SELECT * FROM orders WHERE user_id=123;
• 重点关注key字段是否命中索引，rows是否远小于表总行数；如果type是ALL，UPDATE大概率会进行全表扫描
• FORMAT=JSON比传统文本多出used_columns和query_cost，能判断WHERE条件是否触发索引下推（ICP）
• 注意：改写后的SELECT计划不能完全等同于UPDATE，尤其当UPDATE涉及触发器或外键约束时，实际开销可能更高

别漏掉DBMS_XPLAN.DISPLAY_CURSOR这个关键命令

如果你已经执行过一次批量UPDATE，想要回溯它的真实执行路径（而不是预估），DISPLAY_CURSOR是唯一可靠的手段——它从共享池中抓取已缓存的游标计划。

• 先查出SQL ID：SELECT sql_id, child_number FROM v$sql WHERE sql_text LIKE '%UPDATE%your_table%';
• 再使用SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('abc123xyz', 0, 'ALLSTATS LAST')); ——ALLSTATS LAST会显示实际A-Rows（实际返回行数）、Buffers（逻辑读）、Reads（物理读）
• 对比预估的Rows和实际的A-Rows差距：如果相差10倍以上，说明统计信息严重过期，需要及时收集
• 这个方法对刚执行完的语句最有效；超过Shared Pool老化周期（默认约1小时）后，计划可能已被挤出内存

真实执行计划中的A-Rows和Buffers数值，比预估计划里的Rows和Cost更能暴露性能瓶颈。很多人只看EXPLAIN PLAN FOR就下结论，却忽略了实际执行时索引失效、统计偏差或并发阻塞带来的连锁反应。