MySQL不支持MERGE语句，报ERROR 1064；首选替代是INSERT ... ON DUPLICATE KEY UPDATE，需依赖主键或唯一索引匹配，支持VALUES()取值、多列组合键及子查询（但不可引用目标表），REPLACE INTO仅适用于需重置自增ID等特定场景。
MySQL根本不支持MERGE语句，任何直接写MERGE INTO的尝试都会报错ERROR 1064 (42000)——这不是语法写错了，是引擎压根没实现。
为什么INSERT ... ON DUPLICATE KEY UPDATE是首选替代方案
它最接近标准MERGE语义：匹配唯一键时更新，不匹配时插入。但前提是目标表必须有PRIMARY KEY或UNIQUE约束，否则“重复”无从判断。
- 子查询可以放在
SELECT子句里（如从staging_orders JOIN staging_customers构造源数据），但不能在ON DUPLICATE KEY UPDATE中引用目标表本身，否则触发ERROR 1093 -
VALUES(col)是安全取值方式，避免重复写子查询或字段表达式 - 如果唯一键是多列组合（如
(tenant_id, item_id)），所有列都需在ON条件中参与匹配，漏一列就失效 - 性能依赖索引有效性；源数据量超5000行时建议分批，否则可能锁表过久
什么时候该用REPLACE INTO而不是ON DUPLICATE KEY UPDATE
REPLACE INTO本质是DELETE + INSERT，只在极少数场景下更合适：
- 你明确需要重置自增ID、清空触发器状态、或强制刷新
created_at时间戳 - 目标表没有外键约束（否则
DELETE会失败） - 你提供的是完整行数据，不需要“只更新部分字段”的逻辑
- 注意：
REPLACE INTO会消耗额外的自增值，且无法用VALUES()安全取新值
嵌套子查询必须满足的三个硬性条件
想让INSERT ... SELECT ... ON DUPLICATE KEY UPDATE里的子查询正常工作，得同时满足：
- 子查询必须是独立
SELECT，不能含对目标表（即INSERT INTO后面那张表）的任何引用 - 子查询结果中，用于匹配唯一键的字段值不能重复，否则MySQL按顺序逐条处理，行为可预期但不可控
- 如果子查询涉及
JOIN或WHERE过滤，确保JOIN条件和WHERE谓词不会导致全表扫描——尤其当staging表没建好索引时
跨库同步或复杂逻辑时别硬扛SQL
当源是CSV、API响应、PostgreSQL或ClickHouse时，硬写MySQL SQL做MERGE等效操作极易翻车：
- 字段类型隐式转换失败（比如
TIMESTAMP WITH TIME ZONE往MySQLDATETIME插） - 单批次数据超
max_allowed_packet限制，报Packets larger than max_allowed_packet are not allowed - 目标库唯一约束命名不一致（如MySQL叫
uk_user_email，PG叫users_email_key），导致中间件生成错误语句
真正省事的做法是用Airbyte或Fivetran这类ETL工具——你只定义主键字段和同步逻辑，它自动翻译成对应数据库的合法DML，连事务边界和错误重试都包了。
