SQL Server 中触发器无法直接复用，需将校验逻辑封装为带参数的存储过程（如 usp_validate_order_amount），由各表触发器调用；禁止在触发器内拼接动态SQL或跨库查询，避免事务上下文丢失与性能问题。
SQL Server 里怎么让触发器逻辑能被多个表复用
直接说结论：SQL Server 的 TRIGGER 本身不支持参数化或继承，没法像函数那样“调一次用 everywhere”。所谓“复用”，本质是把校验逻辑抽成独立模块，再通过动态 SQL 或存储过程间接调用——不是复用触发器对象，而是复用校验行为。
常见错误现象：CREATE TRIGGER 里硬写死表名和字段名，换张表就得复制粘贴改一遍；或者试图用 sp_executesql 在触发器里拼接表名，结果报错 The context of the current transaction cannot be determined（事务上下文丢失）。
- 必须把校验逻辑封装进带参数的存储过程，比如
usp_validate_order_amount，接收@table_name、@row_id等参数，内部用sys.dm_exec_describe_first_result_set或临时表查元数据 - 触发器只做三件事：获取当前操作的主键值（如
INSERTED.id）、判断操作类型（IF EXISTS(SELECT 1 FROM INSERTED)）、调用校验存储过程 - 避免在触发器里执行跨库查询或远程调用，会拖慢事务，且容易因锁等待失败
PostgreSQL 中用函数 + 触发器实现校验逻辑复用
PostgreSQL 更适合这事：它允许触发器函数接收参数，还能在函数体内访问 NEW 和 OLD。关键不是“复用触发器”，而是把校验逻辑写进一个通用函数，再让不同触发器调它。
使用场景：订单表、退款表、发票表都要校验“金额不能为负”，但每张表字段名不同（order_amount / refund_value / invoice_total）。
- 写一个
fn_check_non_negative函数，参数为field_value NUMERIC和field_name TEXT，内部抛出RAISE EXCEPTION - 每个表的触发器函数里，显式传入对应字段值：
PERFORM fn_check_non_negative(NEW.order_amount, 'order_amount'); - 注意：不能把字段名当字符串传进去再用
EXECUTE动态取值——这会绕过执行计划缓存，也破坏了触发器的原子性
MySQL 触发器无法传参，怎么绕过限制
MySQL 的触发器语法最僵硬：CREATE TRIGGER 不接受任何参数，也不能调用带输入参数的存储过程（5.7 及以前）。所以“复用”只能靠代码生成或预编译脚本。
性能影响明显：每次新增一张表，就得生成一段几乎一样的触发器定义，字段名一换，其他全抄。维护成本高，但比硬编码强。
- 用 Python 或 Shell 脚本读取表结构（
INFORMATION_SCHEMA.COLUMNS），按模板生成触发器 SQL，例如填入table_name和amount_col - 生成的触发器里，校验逻辑写死但结构一致，比如统一检查
IF NEW.<amount_col> < 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Amount must be non-negative'; END IF; - 别试图用
PREPARE/EXECUTE在触发器里动态执行——MySQL 不允许在触发器中使用动态 SQL
跨数据库迁移时，复用逻辑脚本最容易崩在哪
不是语法差异最大，而是触发器执行时机和事务可见性的隐含规则不同。比如 PostgreSQL 的 AFTER 触发器能看到已提交的变更，而 SQL Server 的 AFTER 触发器看到的是未提交的中间状态；MySQL 的 BEFORE 触发器甚至不能读其他表（除非用存储过程绕开）。
容易被忽略的地方：校验逻辑如果依赖另一个表的最新值（比如检查用户余额是否足够），在 PostgreSQL 里可能读到旧快照，在 SQL Server 里可能被阻塞，而在 MySQL 里直接报错 Can't update table 'xxx' in stored function/trigger。
- 所有跨表校验，必须显式加锁或改用应用层校验，别指望触发器兜底
- 模块化脚本里，要把“校验是否跨表”作为开关参数，生成不同数据库适配的版本
- 测试时别只测单条 INSERT，一定要压测并发 UPDATE —— 复用逻辑在锁竞争下最先暴露问题
