MySQL触发器无法捕获主键/唯一约束冲突错误，错误会直接中断执行并回滚；应改用存储过程+DECLARE HANDLER处理，或在触发器中用SELECT INTO预检+IF分支控制，避免在触发器内执行可能引发约束冲突的DML操作。
触发器里无法捕获主键/唯一约束冲突错误
MySQL 触发器（BEFORE INSERT、BEFORE UPDATE）本身不支持 TRY...CATCH 或类似异常处理机制。当你在触发器中尝试插入违反 UNIQUE 或 PRIMARY KEY 的数据时，MySQL 会直接抛出错误（如 ERROR 1062 (23000): Duplicate entry...），而这个错误**无法在触发器内部被捕获或忽略**——触发器执行会立即中断，整个语句回滚。
常见错误现象：
– 在 BEFORE INSERT 触发器中调用 INSERT INTO log_table，但 log_table 主键冲突 → 整个原始 INSERT 失败
– 试图用 SELECT ... INTO 检查是否存在再决定是否插入，但并发下仍可能撞上唯一约束
实操建议：
– 把“避免重复”的逻辑前移到应用层或存储过程，而非依赖触发器兜底
– 若必须在数据库侧控制，改用 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE 替代裸 INSERT
– 触发器内避免任何可能引发约束冲突的写操作（尤其是对有索引/主键的表）
替代方案：用存储过程封装 + 错误处理器
真正能做异常捕获的是存储过程，不是触发器。你可以把原本想塞进触发器的复杂逻辑拆出来，放到一个带 DECLARE HANDLER 的存储过程中，再由应用显式调用它。
示例场景：插入用户前检查邮箱是否已存在，若存在则更新 last_login，否则插入新记录：
DELIMITER $$
CREATE PROCEDURE upsert_user(IN p_email VARCHAR(255))
BEGIN
DECLARE CONTINUE HANDLER FOR 1062
UPDATE users SET last_login = NOW() WHERE email = p_email;
INSERT INTO users (email, created_at) VALUES (p_email, NOW());
END$$
DELIMITER ;
注意：
– 错误码 1062 是 MySQL 唯一约束冲突的标准错误号，可直接用于 HANDLER
– CONTINUE 表示捕获后继续执行后续语句（这里是 UPDATE）
– 该过程不能被触发器调用（MySQL 禁止触发器内调用含事务/错误处理的存储过程）
触发器中安全的“预检”方式：用 SELECT + IF 判断
虽然不能捕获约束错误，但可以在触发器中用 SELECT ... INTO 预查数据是否存在，再用 IF 控制逻辑分支。这是最常用、也最可控的规避手段。
例如，在 BEFORE INSERT ON orders 中检查客户状态是否为 active：
DELIMITER $$
CREATE TRIGGER check_customer_status
BEFORE INSERT ON orders
FOR EACH ROW
BEGIN
DECLARE v_status VARCHAR(20);
SELECT status INTO v_status FROM customers WHERE id = NEW.customer_id;
IF v_status != 'active' THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Customer is not active';
END IF;
END$$
DELIMITER ;
要点：
– 使用 SIGNAL 主动抛出自定义错误，比让 MySQL 抛约束错误更明确
– SELECT ... INTO 必须确保只返回一行，否则报错；建议加 LIMIT 1 或确保条件唯一
– 不要依赖 NOT FOUND 处理未查到的情况（需配合 DECLARE ... HANDLER FOR NOT FOUND，但仅适用于游标和 SELECT 无结果，不适用于约束校验）
为什么别在触发器里写 INSERT/UPDATE 其他表
看似方便的日志记录、统计更新等操作，一旦目标表存在约束（哪怕只是自增主键），就可能因并发或数据问题导致整个原始语句失败。这不是设计缺陷，而是 MySQL 的事务一致性要求：触发器属于原语句事务的一部分，任一环节失败即全部回滚。
容易被忽略的点：
– INSERT INTO audit_log 可能因 log_time 字段的默认值（如 NOW()）与索引组合产生隐式唯一冲突
– 触发器中调用函数，而函数内部又写了表，等于嵌套了不可控的 DML
– 即使加了 INSERT IGNORE，也无法掩盖主键溢出、外键不匹配等更底层的错误
务实做法：
– 审计类操作统一走应用层异步写入（如消息队列）
– 统计类字段改用 INSERT ... ON DUPLICATE KEY UPDATE 或定期汇总任务
– 如果非要在 DB 层闭环，用事件调度器（EVENT）+ 临时表暂存变更，避开触发器上下文
