insert ... on duplicate key update 比 delete + insert 更安全，因其原子性处理“存在则更新/跳过、不存在则插入”，避免并发下中间表重复或丢失关联，但前提是中间表必须有覆盖关联字段的唯一约束。
INSERT ... ON DUPLICATE KEY UPDATE 为什么比 DELETE + INSERT 更安全
多对多关系更新最常踩的坑，是并发写入时中间表出现重复或丢失关联。比如用户批量改标签，两个请求同时执行 DELETE FROM user_tag WHERE user_id = 123 再各自 INSERT，结果只留下后一个请求的数据。
用 INSERT ... ON DUPLICATE KEY UPDATE 能原子性处理“存在则跳过/更新，不存在则插入”，前提是中间表有唯一约束（如 UNIQUE (user_id, tag_id)）。
- 必须确保中间表主键或唯一索引覆盖关联字段组合，否则
ON DUPLICATE KEY不生效 - 如果只需保证存在、不关心是否更新，
UPDATE子句可简化为UPDATE id = id（MySQL 允许空更新） - PostgreSQL 不支持该语法，得用
INSERT ... ON CONFLICT DO NOTHING或DO UPDATE - 注意：该语句会触发自增 ID 变化（即使实际没插入新行），可能影响后续
LAST_INSERT_ID()逻辑
如何用 REPLACE INTO 避免手写 DELETE + INSERT 逻辑
REPLACE INTO 是 MySQL 特有方案：先按主键/唯一键尝试删除已有行，再插入新行。它比手动分两步更简短，也规避了中间状态残留问题。
但它的“先删后插”本质带来副作用：外键级联操作会被触发两次，自增 ID 会跳变，且无法区分“新增”和“替换”行为。
- 仅适用于中间表无其他依赖字段（比如只有
user_id和tag_id），否则整行被覆盖，可能误清空扩展字段 - 如果中间表有
created_at DEFAULT CURRENT_TIMESTAMP，每次REPLACE都会刷新该时间，失去原始关联时间点 - SQLite 支持
REPLACE，但 PostgreSQL 和 SQL Server 完全不支持，跨数据库迁移时要重写
WHERE IN (...) 更新性能崩掉的真正原因
想一次性更新多个关联，有人写 UPDATE user_tag SET is_active = 1 WHERE (user_id, tag_id) IN ((123,45),(123,67),(123,89))。这在数据量稍大时会明显变慢，甚至锁表。
根本原因是：MySQL 对多列 IN 元组的索引利用效率低，尤其当元组数超百，优化器常放弃使用联合索引，退化为全表扫描。
- 替代做法是拆成多个单条件
OR（如WHERE (user_id = 123 AND tag_id = 45) OR (user_id = 123 AND tag_id = 67)），MySQL 对这种能更好命中索引 - 更稳妥的是用临时表 + JOIN：把目标元组批量写入临时表，再用
UPDATE user_tag t JOIN temp_batch b ON t.user_id = b.user_id AND t.tag_id = b.tag_id - 注意：
IN列表长度受max_allowed_packet和服务端参数限制，超长直接报错Packets larger than max_allowed_packet are not allowed
事务里混用 INSERT IGNORE 和 SELECT FOR UPDATE 的顺序陷阱
想“确保某组关联存在，若不存在则插入”，又怕并发冲突，有人在事务里先 SELECT ... FOR UPDATE 查，再根据结果决定是否 INSERT IGNORE。看似严谨，实则留了竞态窗口。
因为 SELECT FOR UPDATE 只锁住已存在的行，对不存在的 (user_id, tag_id) 组合不加锁（间隙锁需配合范围查询才生效），另一个事务仍可同时插入相同元组。
- 正确做法是直接
INSERT IGNORE，靠唯一索引拦截重复；再用SELECT ROW_COUNT()判断是否真插入了新行 - 如果后续逻辑依赖“刚插入的行 ID”，注意
INSERT IGNORE成功时不改变LAST_INSERT_ID()，失败时也不变——不能靠它判断成败 - 在 RR 隔离级别下，若想彻底避免幻读，得对整个范围加锁，比如
SELECT ... FOR UPDATE WHERE user_id = 123（锁定所有该用户的关联行及间隙）
中间表看着简单，但每一步写法都在和隔离级别、索引策略、存储引擎特性较劲。最容易被忽略的，其实是那个没写的唯一约束——没有它，上面所有方案都会失效。
