INSERT IGNORE不生效的主因是表未建PRIMARY KEY或UNIQUE约束，它仅对Duplicate entry冲突静默跳过，无索引则完全无效；其他错误（如字段超长、类型不匹配）仍报错。
INSERT IGNORE 为什么有时不生效
MySQL 的 INSERT IGNORE 看似简单，但实际中常因主键或唯一索引缺失而完全失效——它只在遇到 Duplicate entry 错误时跳过，没建约束就等于裸插。另外，它对警告（比如字段截断）也“忽略”，可能掩盖数据质量问题。
使用前务必确认表上有 PRIMARY KEY 或 UNIQUE 约束，且冲突字段明确覆盖你要去重的维度（比如 email 或 order_id）。
- 只适用于 MySQL；PostgreSQL 和 SQL Server 不支持该语法
- 不会返回“影响行数=0”来区分是否跳过，需靠
ROW_COUNT()或应用层日志判断 - 如果插入多条，其中某条失败会导致整批被忽略（除非开启
INSERT IGNORE ... VALUES (...), (...)的批量模式）
ON DUPLICATE KEY UPDATE 怎么安全更新而不覆盖关键字段
这是 MySQL 更可控的方式：冲突时执行 UPDATE，但必须小心指定哪些字段允许被更新。例如用户注册时想保留首次创建时间，就不能写 created_at = NOW()。
INSERT INTO users (email, name, created_at)
VALUES ('a@b.com', 'Alice', NOW())
ON DUPLICATE KEY UPDATE name = VALUES(name);
VALUES(name) 表示本次 INSERT 中为 name 提供的值，不是当前行旧值。这种写法避免了用子查询或 JOIN 带来的性能开销。
- 仅对触发唯一约束冲突的那行生效，不影响其他行
- 不能在
UPDATE子句中引用未在INSERT列表中出现的字段（会报Unknown column） - 若需条件更新（如“仅当新 name 非空才覆盖”），得用
IF(VALUES(name) != '', VALUES(name), name)
REPLACE INTO 的隐式 DELETE 风险在哪
REPLACE INTO 实际是“删+插”两步：先按主键/唯一键查，存在则 DELETE 原记录，再 INSERT 新记录。这会引发几个问题：
- 自增 ID 可能跳变（旧记录 ID 被释放，新记录获得新 ID）
- 外键级联删除可能意外触发（如果关联表设了
ON DELETE CASCADE） - 触发器会被执行两次（
BEFORE DELETE+BEFORE INSERT），逻辑容易错乱 - 在有
ON UPDATE CURRENT_TIMESTAMP的字段上，时间戳总会刷新，哪怕内容没变
除非你明确需要重置时间戳或强制刷新整行，否则优先选 INSERT ... ON DUPLICATE KEY UPDATE。
PostgreSQL 和 SQLite 怎么做等效处理
PostgreSQL 用 INSERT ... ON CONFLICT，语义清晰、能力更强。SQLite 从 3.24.0 开始支持几乎相同的语法，兼容性已很好。
INSERT INTO users (email, name) VALUES ('a@b.com', 'Alice')
ON CONFLICT (email) DO UPDATE SET name = EXCLUDED.name;
EXCLUDED 是 PostgreSQL/SQLite 关键字，代表本次试图插入但冲突的那行数据。注意括号里要写明冲突检测的列名（如 (email)），不能只写表名。
- SQL Server 用
MERGE，语法更冗长，且易因NOT MATCHED BY SOURCE逻辑误删数据 - 所有数据库都不支持在冲突子句里调用非确定性函数（如
NOW()、RANDOM()）作为更新值，除非包装在子查询中 - 如果冲突列是组合唯一索引（如
(user_id, category)），ON CONFLICT必须写全字段
真正难的不是语法选择，而是提前定义清楚“什么是重复”——是 email 相同？还是 phone + name 组合相同？这个业务规则一旦定错，后面所有去重逻辑都会偏航。
