可行但需规避无主键、无索引等陷阱，否则易触发ORA-30926或锁表超时；根本原因是归档表缺乏唯一约束，导致ON子句匹配不稳定；正确做法是在USING中用ROW_NUMBER()去重并限定分区。
直接用 MERGE INTO 更新历史归档表是可行的，但必须绕开归档表常见的“无主键、无索引、数据量大、结构松散”陷阱——否则极易触发 ORA-30926 或锁表超时，甚至让归档任务卡死数小时。
为什么归档表上 MERGE 容易报 ORA-30926？
归档表通常缺乏唯一约束和索引，而 MERGE 的 ON 子句要求：对目标表每一行，源数据最多只能有一行与之匹配。归档表若存在重复业务键（比如多个同 order_id 的历史快照）、或源查询未去重，就会触发该错误。
- 典型现象：
ORA-30926: unable to get a stable set of rows in the source tables - 归档场景常见诱因：源数据来自分区表导出、ETL中间表未清洗、按时间范围拉取时未加
DISTINCT或ROW_NUMBER() - 别指望靠目标表加唯一索引解决——归档表往往不允许改结构，且加索引本身就会拖慢归档过程
- 正确解法是：在
USING子句里主动收拢源数据，确保用于ON的字段组合全局唯一
USING 子句怎么写才安全？
不能直接 USING archive_log，得把源数据“压平”成逻辑单行。关键不是查得多，而是查得稳。
- 优先用
ROW_NUMBER() OVER (PARTITION BY business_key ORDER BY update_time DESC)取最新一条，而不是MAX()聚合后丢失上下文 - 避免在
USING里JOIN多张归档相关表——容易放大行数；改用LEFT JOIN+COALESCE或提前物化到临时表 - 如果归档表有时间分区（如按月），务必在
USING查询中显式限定分区，例如WHERE dt >= '202601' AND dt ，防止全表扫描 - 测试阶段先跑等价
SELECT：把USING子查询单独执行，COUNT(*)和COUNT(DISTINCT business_key)对比，差值为 0 才算过关
UPDATE SET 里哪些字段不能乱动？
归档表字段常含 NOT NULL、CHECK 约束或默认值逻辑，但 MERGE 不校验这些——它只管语法通不通，不管业务合不合理。
-
WHEN MATCHED THEN UPDATE SET必须显式列出所有NOT NULL字段，哪怕值不变；漏掉一个，整条更新就失败 - 别在
SET里写SYSDATE或SEQ.NEXTVAL这类动态值——归档表通常禁用序列，且时间戳应保留原始归档时刻 - 如果归档表有虚拟列或函数索引依赖的字段（如
UPPER(name)），确保SET值与函数输出一致，否则后续查询可能走不到索引 - 慎用
WHERE子句过滤更新行：它只作用于已匹配的行，不影响ON匹配逻辑；但归档场景下，WHERE t.status != 'ARCHIVED'这类条件能避免误更新已封存记录
大批量归档更新时性能卡点在哪？
不是 SQL 写得不够短，而是 Oracle 在归档表上做 MERGE 时，默认会尝试维护所有索引和触发器——而归档表往往挂了一堆已失效的索引和审计触发器。
- 执行前用
ALTER TABLE archive_log DISABLE ALL TRIGGERS关掉触发器（记得事后恢复） - 如果归档表有非关键索引，临时
UNUSABLE它们：ALTER INDEX idx_archive_dt UNUSABLE，MERGE 完再REBUILD - 别用单次百万级
MERGE——分批更稳。用USING子查询外层套WHERE ROWNUM ，配合循环 PL/SQL 调用，每次提交 - 最易被忽略的一点：归档表统计信息往往过期。跑一次
DBMS_STATS.GATHER_TABLE_STATS再执行MERGE，执行计划可能从全表扫描变成索引快速扫描
