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就下结论，却忽略了实际执行时索引失效、统计偏差或并发阻塞带来的连锁反应。