INSERT IGNORE在存储过程中合法但仅发warning不报错，无法用DECLARE HANDLER捕获；REPLACE INTO是DELETE+INSERT有副作用；ON DUPLICATE KEY UPDATE才是精确可控、事务安全的冲突处理方案。
INSERT IGNORE在存储过程中能用，但警告不报错
在存储过程中直接写INSERT IGNORE INTO是合法的，MySQL 会按预期跳过重复键行，不中断执行流程。但它不会抛出异常，只生成 warning（可通过SHOW WARNINGS查看），这意味着你无法靠DECLARE ... HANDLER捕获它——handler 只响应 error，不响应 warning。
常见误判点：
- 以为
INSERT IGNORE失败时会触发SQLEXCEPTIONhandler，实际不会 - 在循环插入中依赖错误跳转逻辑，结果因无错误而继续执行后续语句，造成意外交互
- 未检查
ROW_COUNT()，误以为所有行都插入成功（INSERT IGNORE重复时ROW_COUNT()返回 0）
REPLACE INTO本质是DELETE+INSERT，慎用于有外键或触发器的表
REPLACE INTO不是“覆盖更新”，而是先尝试 DELETE 原有行、再 INSERT 新行。这个过程在存储过程中同样可用，但副作用明显：
- 自增主键可能跳号（DELETE 触发 ID 释放，新 INSERT 拿到下一个值）
- 如果表被其他表通过
FOREIGN KEY ... ON DELETE CASCADE引用，会级联删数据 - 触发器（如
BEFORE DELETE、AFTER INSERT）会被完整执行两次 -
ROW_COUNT()返回值是 2（删 1 行 + 插 1 行），而非 1，影响后续判断逻辑
真正可控的方案：ON DUPLICATE KEY UPDATE
这是唯一能在存储过程中**精确控制冲突行为**且**保持事务原子性**的方式。它不删除原记录，只更新指定字段，也不会触发 DELETE 相关逻辑。
使用要点：
- 必须确保目标列上有
PRIMARY KEY或UNIQUE索引，否则ON DUPLICATE KEY UPDATE不生效 - 更新字段不能包含在唯一约束列中（例如唯一索引是
(email)，就不能写email = VALUES(email)，会报错） - 可安全配合
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION，因为冲突不报错，只有语法或权限类错误才触发 - 推荐搭配
VALUES(col_name)函数使用，避免重复写字面值，例如：INSERT INTO user (id, name) VALUES (1, 'a') ON DUPLICATE KEY UPDATE name = VALUES(name)
存储过程里怎么知道哪一行冲突了
MySQL 存储过程本身不提供“逐行冲突反馈”机制。你只能通过间接方式判断：
- 单条
INSERT ... ON DUPLICATE KEY UPDATE后查ROW_COUNT()：返回 1 表示插入，2 表示更新（即发生了冲突） - 批量
INSERT ... ON DUPLICATE KEY UPDATE时，ROW_COUNT()返回总影响行数，但无法区分哪几行是插入、哪几行是更新 - 若需精确追踪，得拆成循环+单条语句，并在每次后检查
ROW_COUNT()，代价是性能下降 - 不要依赖
GET DIAGNOSTICS——它对ON DUPLICATE KEY UPDATE不返回冲突键信息，只适用于真正报错的场景
最常被忽略的是：哪怕用了ON DUPLICATE KEY UPDATE，如果唯一索引字段本身为NULL（比如允许 NULL 的UNIQUE索引），MySQL 会认为多条 NULL 值不冲突——这和业务预期常常不一致，务必提前确认索引字段是否设为NOT NULL。
