触发器是实现动态组合唯一校验的唯一可行机制，须在before insert/update中显式查表，注意null比较、update自检、错误信息携带列名与值，跨表校验属高风险补救，首选原生unique约束或外键。
BEFORE INSERT/UPDATE 中手动查重是唯一可行路径
触发器无法让数据库引擎自动识别“组合唯一”语义，必须在 BEFORE INSERT 或 BEFORE UPDATE 里显式查表判断。UNIQUE 约束本身不支持动态逻辑（比如跳过 NULL、忽略大小写、按状态过滤），而触发器是绕过这个限制的唯一机制。
常见错误是只写 INSERT 触发器，漏掉 UPDATE 场景——更新时若修改了参与校验的列，同样可能造成重复；还容易忘记加 WHERE id != NEW.id，导致更新自己那行时误判为冲突。
- 用
SELECT COUNT(*) INTO @cnt而非EXISTS或LIMIT 1，避免空结果集引发变量未初始化问题 - 对可能为 NULL 的列，别用
=直接比较，改用(col NEW.col)（MySQL）或(col = NEW.col OR (col IS NULL AND NEW.col IS NULL)) - 如果业务要求“仅当
status = 'active'时才校验”，WHERE 条件里必须带上这个过滤，否则会把已失效的旧记录也纳入比对
MySQL 中 SIGNAL 报错必须带具体值和列名
只写 SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '违反唯一约束' 是无效的。生产环境需要快速定位哪几列、什么值冲突，否则 DBA 只能翻日志再反查原始 SQL。
错误信息里必须拼接参与校验的列名和实际值，且建议对值做简单转义（如用 CONCAT + REPLACE 去掉换行）。虽然触发器没有用户输入，但保持这个习惯能降低未来扩展风险。
- 示例：
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = CONCAT('组合唯一冲突: tenant_id=', NEW.tenant_id, ', email=', COALESCE(NEW.email, 'NULL')); - 别在触发器里调用自定义函数做校验——函数内若含查询，同样触发
ERROR 1442 -
SIGNAL必须在IF分支内显式调用，漏写就等于没校验
跨表组合唯一？触发器只是临时补位，不是正解
SQL 标准中，UNIQUE 约束只接受本表列名列表，不支持子查询或 JOIN。试图写 UNIQUE (SELECT email FROM Users) 会直接报语法错误。所以真要跨表判断（比如 Orders.email 不能与 Users.email 重复），只能靠触发器兜底。
但这属于高风险操作：性能差（每次插入都跨表查）、难维护（逻辑散落在触发器里）、易出错（漏处理多行、锁升级、事务回滚不彻底）。它只应在极少数场景下使用——比如历史表无法加外键、多租户隔离策略强制分表、或遗留系统不允许改表结构。
- 必须用
INSTEAD OF INSERT（SQL Server）或BEFORE INSERT（MySQL）而非AFTER，否则数据已写入，回滚代价更大 - 跨表查重优先用
EXISTS而非COUNT(*) > 0，减少扫描量和锁范围 - 务必用
THROW（SQL Server）或SIGNAL（MySQL）抛出带错误号的异常，否则事务不会自动回滚
真正可靠的方案永远在建表阶段
触发器里的组合唯一校验，本质是设计层缺位后的补救。最可靠的做法，是在建表时就用原生机制固化规则：
- 单表组合唯一：直接加
UNIQUE (col1, col2)，这是零成本、高性能、优化器可感知的方案 - 跨表引用唯一：被引用字段（如
Users.email）设为UNIQUE，目标表（如Orders）加外键指向它——这才是标准参照完整性 - SQL Server 2016+ 支持计算列 + 唯一索引：比如
ALTER TABLE Orders ADD email_normalized AS LOWER(email) PERSISTED，再建UNIQUE INDEX IX_Orders_email ON Orders(email_normalized)
触发器的复杂度和隐患，往往远超它所解决的问题。只要表结构允许调整，就别把它当第一选择。
