SQL触发器不能替代UNIQUE约束实现跨表唯一性——因UNIQUE仅限单表，不支持跨表引用；可靠方案是外键+唯一约束组合，或SQL Server 2016+的计算列+唯一索引，触发器仅作遗留场景临时补位。
SQL 触发器不能替代 UNIQUE 约束来实现跨表唯一性检查——它只是兜底手段，且极易出错、难维护、性能差。 真正可靠的跨表唯一性，必须靠外键 + 唯一约束组合，或物化视图/计算列 + 索引（SQL Server 2016+），触发器只应在极少数无法改表结构的遗留场景中临时补位。
为什么不能直接用 UNIQUE 约束跨表？
UNIQUE 约束作用范围仅限单表，数据库引擎不支持在 CONSTRAINT 定义中引用另一张表的列。试图写 UNIQUE (SELECT email FROM Users) 会直接报语法错误——CREATE TABLE 或 ALTER TABLE 的 UNIQUE 子句只接受本表列名列表，不支持子查询或 JOIN。
INSTEAD OF 触发器做跨表唯一校验的实操陷阱
若真要硬上触发器（例如历史表无法加外键、多租户隔离等特殊场景），INSTEAD OF INSERT 比 AFTER INSERT 更可控，但必须注意：
- 必须显式
INSERT原始数据，否则行就丢了；漏写会导致静默丢数据 - 跨表查重需用
EXISTS而非COUNT(*) > 0，避免全表扫描和锁升级 - 必须用
THROW抛出带错误号的异常（如THROW 50001, 'Email already exists in Users table', 1），否则事务不会回滚 - 触发器内不能调用含事务控制的存储过程，否则可能引发嵌套事务冲突
示例（SQL Server）：
CREATE TRIGGER tr_CheckEmailUniqueness ON Orders
INSTEAD OF INSERT
AS
BEGIN
IF EXISTS (
SELECT 1 FROM inserted i
INNER JOIN Users u ON i.email = u.email
)
BEGIN
THROW 50001, 'Email conflict with Users table', 1;
RETURN;
END
INSERT INTO Orders (email, order_date, amount)
SELECT email, order_date, amount FROM inserted;
END;
比触发器更可靠、更高效的替代方案
跨表唯一性本质是「逻辑主键」问题，应优先走数据库设计层解决：
- 把被引用字段（如
Users.email）设为UNIQUE，再在目标表（如Orders）建外键指向它——这是最标准做法 - 若需组合唯一（如
tenant_id + email），在Users表上建多列UNIQUE约束，并让Orders.tenant_id外键关联Users.tenant_id - SQL Server 2016+ 可用计算列 + 唯一索引：
ALTER TABLE Orders ADD email_normalized AS LOWER(email) PERSISTED，再建UNIQUE INDEX IX_Orders_email ON Orders(email_normalized)，配合Users表同策略对齐
触发器真正的价值不在“实现唯一性”，而在“记录冲突原因”或“异步通知”——比如插入失败时自动往 AlertLog 写一条记录，而不是扛起校验主力。
跨表唯一性一旦依赖触发器，后续迁移、分库、读写分离都会立刻暴露问题：触发器不复制到从库、不生效于 bulk insert、绕过 ORM 的 save 方法……这些不是“可能”，而是“必然发生”。设计阶段没想清楚外键路径，后期补触发器，等于给系统埋定时炸弹。
