SQL执行批量更新时如何查看详细的执行计划

Oracle中可用EXPLAIN PLAN FOR预览UPDATE执行计划，仅解析不执行，安全但需后续调用DBMS_XPLAN.DISPLAY查看；含绑定变量时无法反映选择率影响，且复杂语句硬解析可能争抢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就下结论，却忽略了实际执行时索引失效、统计偏差或并发阻塞带来的连锁反应。