MySQL 5.6从2.6版起支持EXPLAIN UPDATE但实际不可靠，8.0.19+虽能输出执行计划却常误判type为ALL，因优化器对UPDATE额外估算锁、undo日志和索引更新成本，建议用EXPLAIN SELECT *模拟WHERE条件验证索引使用。
UPDATE在MySQL 5.6 vs 8.0中执行计划差异明显
MySQL 5.6.2起才支持EXPLAIN UPDATE，但实际可用性极低：5.6版本常报错或返回空key字段；8.0.19+虽能输出执行计划，但type字段仍可能误判为ALL（全表扫描），而真实执行时却走了索引。这不是bug，而是优化器对UPDATE的代价估算模型与SELECT不同——它会预估锁开销、undo日志写入、二级索引更新等隐式成本，导致“看似走索引，实则降级”。
实操建议：
- 永远用
EXPLAIN SELECT *模拟WHERE条件，而不是依赖EXPLAIN UPDATE - 对比5.6和8.0的
SHOW INDEX FROM table_name输出，注意8.0新增的visible列——不可见索引会被优化器忽略 - 若升级到8.0后UPDATE变慢，先检查是否启用了
optimizer_switch='use_index_extensions=off'（某些场景下开启反而劣化）
PostgreSQL中UPDATE的MVCC行为随版本演进显著变化
PG 12之前，UPDATE本质是“删除旧行+插入新行”，即使只改一个字段，也会生成新tuple并留下死元组；PG 12引入heap-only tuples (HOT)优化，当更新不涉及索引列且有足够空闲空间时，可复用原页内空间，避免索引更新。但这个优化依赖fillfactor和autovacuum配置——老版本默认fillfactor=100，新版本推荐设为80～90。
常见错误现象：
- PG 11迁移至13后，批量
UPDATE反而更慢 → 检查pg_stat_all_tables.n_dead_tup是否飙升，确认autovacuum_vacuum_scale_factor是否仍用旧值（0.2） - WHERE条件含
ctid或xmin时，PG 14+会绕过HOT路径，直接走常规更新 → 这类写法在老版本能提速，在新版本反而失效
SQL Server 2016+对UPDATE加锁策略做了底层调整
SQL Server 2014及更早版本中，UPDATE默认请求U锁（update lock），再升级为X锁；2016起引入optimistic locking模式（需启用READ_COMMITTED_SNAPSHOT），将锁粒度从页级降至行级，但代价是tempdb压力陡增。若未同步调大tempdb文件，UPDATE会卡在WRITELOG等待上。
关键参数差异：
-
sys.dm_exec_requests.wait_type = 'PAGELATCH_UP'→ 老版本典型锁争用，需加索引或拆分热点页 -
sys.dm_exec_requests.wait_type = 'PAGEIOLATCH_SH'→ 新版本tempdb IO瓶颈，需检查tempdb.sys.dm_db_file_space_usage - 执行
UPDATE前务必确认ALTER DATABASE [db] SET READ_COMMITTED_SNAPSHOT ON已生效，否则新锁机制不激活
Oracle 12c vs 19c对WHERE条件中函数处理逻辑不一致
Oracle 12.1对WHERE UPPER(name) = 'ABC'这类写法，即使name上有函数索引，也倾向使用全表扫描；19c优化器增加了adaptive plan能力，运行时可根据实际数据分布动态切换执行路径——但前提是统计信息必须DBMS_STATS.GATHER_TABLE_STATS刷新过，且OPTIMIZER_DYNAMIC_SAMPLING等级≥2。
容易踩的坑：
- 12c迁移到19c后
UPDATE变慢 → 不是性能退化，而是旧执行计划被清空，新计划首次运行时采样不足，触发保守路径 - 显式创建函数索引
CREATE INDEX idx_up_name ON t(UPPER(name))在12c必须配合WHERE UPPER(name) = ...才能命中；19c允许WHERE name = 'abc'通过函数索引反向匹配，但需设置optimizer_features_enable='19.1.0' - 19c中
/*+ OPT_PARAM('_fix_control' '26992877:1') */可强制启用新函数索引优化，但该隐藏参数仅在补丁集≥19.16后有效
真正影响跨版本UPDATE效率的，往往不是语法或功能增减，而是优化器对“锁”“日志”“死元组清理”这些后台动作的建模方式变了。同一句SQL，在不同版本里走的物理路径可能完全不同——别只盯着EXPLAIN输出，得看INNODB_TRX、pg_stat_progress_vacuum或sys.dm_tran_locks里真实的资源占用。
