不能用触发器实现可靠跨表排他性约束，应优先通过UNIQUE约束与外键等DDL手段保障；若必须用触发器，则须用INSTEAD OF INSERT、EXISTS校验、THROW回滚，并确保索引完备。
不能用触发器实现可靠、可维护的跨表排他性约束——它只是临时补位手段，且极易导致静默丢数据或死锁。
INSTEAD OF INSERT 是唯一可控的起点
想在插入前查 Users 表判断 email 是否已存在，必须用 INSTEAD OF INSERT，而不是 AFTER INSERT 或 BEFORE INSERT。后者无法阻止原始 INSERT 执行，校验通过后数据已落库；而 INSTEAD OF 能拦截操作，给你完全控制权。
- 必须显式执行
INSERT INTO Orders ... SELECT ... FROM inserted，漏写就等于丢数据 - 不能依赖
COUNT(*) > 0做冲突判断——会引发全表扫描和共享锁升级，高并发下易死锁 - 必须用
EXISTS+ 索引字段关联，例如EXISTS (SELECT 1 FROM Users u WHERE u.email = i.email) - 校验失败必须用
THROW（SQL Server）或SIGNAL（MySQL 5.5+），仅RETURN不会回滚事务
触发器里调 SELECT 查另一张表的风险点
跨表查询本身不报错，但实际运行中极易踩坑：
- Users 表的
email列没建索引？EXISTS也会变全表扫描，延迟飙升 - 如果 Users 表正被大事务更新（如批量导入），你的触发器会等锁，拖慢所有 Orders 插入
- SQL Server 中，触发器内不能调用含
BEGIN TRAN的存储过程，否则嵌套事务出错 - MySQL 8.0+ 支持函数索引，但触发器里用
LOWER(email)查询时，若 Users 表没建对应函数索引，照样慢
比触发器更稳更快的替代路径
真正要落地跨表排他性，优先走数据库设计层，而非逻辑层兜底：
- 把
Users.email设为UNIQUE，再在Orders上加外键FOREIGN KEY (email) REFERENCES Users(email)—— 这是最标准解法 - 若需多租户隔离（如
tenant_id + email组合唯一），在 Users 表建联合唯一约束，并让 Orders.tenant_id 外键指向 Users.tenant_id - SQL Server 2016+ 可用计算列：
ALTER TABLE Orders ADD email_lower AS LOWER(email) PERSISTED，再建唯一索引UNIQUE INDEX IX_Orders_email_lower ON Orders(email_lower)，同时 Users 表也做同样处理并索引对齐
触发器的复杂度不在语法，而在它把本该由 DDL 和索引保证的事，硬塞进运行时逻辑里——一旦表结构微调、索引失效、或并发量上来，问题就从“查不到”变成“查得慢”“锁住整个表”“事务莫名回滚”。真要上，务必配好索引、禁用嵌套事务、全程用 EXISTS + THROW，并且只留给改不了表结构的遗留系统。
