INSERT IGNORE 是 MySQL 中最轻量的冲突跳过方案，静默忽略主键或唯一索引冲突，不报错、不更新、不加锁；PostgreSQL 对应的是 ON CONFLICT (列) DO NOTHING，需显式指定冲突目标且语法更严格；SQL Server 则需用 MERGE 模拟，但开销大、易争抢。
INSERT IGNORE 是最轻量、最直接的解法，尤其适合“只插入新数据、跳过已存在记录”的场景。它不加锁、不更新、不报错，真正实现静默跳过。
MySQL 用 INSERT IGNORE 跳过冲突行
当表有 PRIMARY KEY 或 UNIQUE 索引时，INSERT IGNORE 会把违反约束的行直接忽略，其余行照常插入。
- 常见错误现象：
ERROR 1062 (23000): Duplicate entry 'xxx' for key 'PRIMARY'—— 这说明你没加任何容错，直接用了裸INSERT - 执行示例：
INSERT IGNORE INTO users (id, name) VALUES (1,'Alice'),(2,'Bob'),(1,'Charlie');→ 第二个(1,'Charlie')被跳过，不报错也不插入 - 注意：它只忽略由唯一键或主键冲突引发的错误；字段超长、
NOT NULL插NULL等仍会报错并中止整条语句 - 返回值中
rows affected少于VALUES行数，差值就是被忽略的重复行数，可用于统计去重效果
PostgreSQL 用 ON CONFLICT DO NOTHING 精准控制
PostgreSQL 没有 IGNORE，但 ON CONFLICT 更明确——必须指定冲突依据（列名或约束名），不能省略 DO NOTHING。
- 使用场景：你想按
email去重，而表上有CREATE UNIQUE INDEX idx_users_email ON users(email); - 写法示例：
INSERT INTO users (id, email) VALUES (1,'a@b.com'),(2,'c@d.com') ON CONFLICT (email) DO NOTHING; - 更安全的写法是显式引用约束名：
ON CONFLICT ON CONSTRAINT idx_users_email DO NOTHING，避免列名歧义 - 如果漏写
DO NOTHING，语法直接报错；也不能写成DO UPDATE SET，否则就不是“跳过”了
SQL Server 用 MERGE 模拟跳过逻辑
MERGE 不是 INSERT 变体，而是匹配驱动型语句。想“只插入不更新”，就得严格限定分支逻辑。
- 必须写全
WHEN NOT MATCHED THEN INSERT，且不能带WHEN MATCHED分支，否则可能误触发更新或失败 - 源数据要用
USING (VALUES ...)构造，例如：MERGE users AS t USING (VALUES (1,'Alice'),(2,'Bob')) AS s(id,name) ON t.id = s.id WHEN NOT MATCHED THEN INSERT (id,name) VALUES (s.id,s.name); - 目标表必须有唯一索引（如
id主键），否则ON条件无法保证单行匹配，行为不可控 - 别指望
MERGE像INSERT IGNORE那样轻量——它涉及匹配扫描、锁资源，高并发下仍可能争抢
为什么别用 ON DUPLICATE KEY UPDATE 来“跳过”？
它本质是“查+锁+可能更新”，开销远高于跳过需求本身，还容易卡住。
- 主键冲突时不报错而是卡住，是因为它在检测前就加了
X lock和insert intention lock，多个事务插入相同键会互相等待 - 即使写
ON DUPLICATE KEY UPDATE id=id这种伪更新，照样锁行、照样触发索引维护，毫无性能优势 - 批量插入时若
VALUES中主键乱序，InnoDB 间隙锁会交叉加锁，引发死锁风险；必须提前在应用层ORDER BY id ASC - 真需要更新字段时，建议改用
SELECT ... FOR UPDATE显式加锁再UPDATE，逻辑更可控
INSERT IGNORE 不关心顺序，但 SQL Server 的 MERGE 和 PostgreSQL 的 ON CONFLICT 对唯一性判断都依赖底层索引结构，一旦建表时多加了二级唯一索引，就可能引入额外锁竞争。 
