唯一索引是防重复插入的首选，触发器仅用于复杂业务校验；建索引前需确认NULL容忍性、字段顺序及查询字段索引；触发器中必须用SIGNAL报错且限于BEFORE阶段；AFTER触发器不可修改原表；ON DUPLICATE KEY UPDATE不触发UPDATE类触发器。
唯一索引必须先建，触发器只是兜底
95% 的重复插入问题，靠 UNIQUE KEY (user_id, order_no) 就能拦住。MySQL 在 INSERT 时会自动检查唯一约束，冲突直接报错 ERROR 1062 (23000): Duplicate entry 'xxx' for key 'xxx'，根本不会走到触发器里。
触发器只该用于那些索引管不了的场景：比如要校验「过去 5 分钟内同一用户不能提交超过 3 次」，或者「订单状态 + 时间窗口组合唯一」这类带逻辑判断的幂等控制。
常见错误是跳过索引、直接上触发器——结果每次插入都触发 SELECT ... FROM users WHERE email = NEW.email，若没给 email 加索引，就是全表扫描，QPS 上不去，锁还容易堵死。
- 建唯一索引前，先确认字段是否允许
NULL：主键不允许NULL，普通唯一索引允许多个NULL - 多列唯一索引要按查询顺序排列，比如常查
(tenant_id, biz_id)，就别写成(biz_id, tenant_id) - 触发器里用到的查询字段，必须有索引，否则性能崩得比业务还快
BEFORE INSERT 里不能只查不报错
很多人写触发器只做 SELECT COUNT(*) INTO @cnt FROM orders WHERE order_no = NEW.order_no，然后啥也不干——这完全无效。MySQL 触发器里没有 RETURN 或 ROLLBACK，不主动中断，插入照常发生。
正确做法是查完立刻用 SIGNAL 报错：
IF @cnt > 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'duplicate submit'; END IF;
注意两点：
-
SIGNAL必须在BEFORE INSERT阶段抛出，AFTER阶段已无法阻止写入 - 别在触发器里写
SELECT ... FOR UPDATE—— 校验只是读操作，加锁会引发间隙锁，高并发下排队卡死 - 如果要用
SELECT ... LOCK IN SHARE MODE（MySQL 8.0+），也得想清楚：它仍有锁开销，不如索引硬控来得干脆
AFTER 触发器改本表会递归报错
ERROR 1442 (HY000): Can't update table 'orders' in stored function/trigger because it is already used by statement... 这不是警告，是 MySQL 硬性拦截——语法层就拒绝执行。
但真正危险的是“伪安全”写法：比如在 BEFORE INSERT 里只设 NEW.status = 'pending'，然后在 AFTER INSERT 里又去 UPDATE orders SET updated_at = NOW() WHERE id = NEW.id。这会再次触发 BEFORE UPDATE 和 AFTER UPDATE，形成链式调用。
-
BEFORE触发器中操作NEW或OLD是安全的，不会引发新事件 -
AFTER触发器中只能操作其他表（如日志表、统计表），不能碰原表 - 真需要更新本表？拆成两条语句：先
INSERT，再由应用层发一次UPDATE，明确分离职责
INSERT ... ON DUPLICATE KEY UPDATE 不触发 UPDATE 类触发器
这条语句看着像“先插再更”，但 MySQL 内部把它当一次“插入尝试”。即使实际执行了更新逻辑，也只走 BEFORE INSERT 和 AFTER INSERT，BEFORE UPDATE 和 AFTER UPDATE 完全不会执行。
如果你依赖 AFTER UPDATE 做消息通知或状态同步，用这个语法就会漏掉。
- 需要统一处理 insert/update 场景？把核心逻辑抽成存储过程，在
BEFORE INSERT和BEFORE UPDATE里都调用它 - 业务强依赖“这次到底是新增还是更新”？别用
ON DUPLICATE KEY UPDATE，改用显式INSERT+INSERT failed → UPDATE两步流程 - 注意：
NEW.id在ON DUPLICATE KEY UPDATE的AFTER INSERT中，可能是已存在行的主键值，不能默认当作新生成 ID 使用
最容易被忽略的点：触发器里的校验逻辑一旦涉及跨表读取最新状态（比如查余额、查配额），就不再是纯幂等控制，而是实时业务决策——这时候该交给应用层配合分布式锁来做，而不是塞进数据库触发器里硬扛。
