不支持。所有主流数据库的sql触发器（mysql、postgresql、sql server）均不支持直接传参，这是语法和执行模型的硬性限制：sql server无参数入口，仅能通过inserted/deleted访问数据；postgresql的tg_argv是定义时硬编码的只读字符串数组，需手动类型转换且不可动态修改；mysql则完全无类似机制，仅能依赖会话变量或配置表间接控制行为。
不支持。所有主流数据库的 SQL 触发器（MySQL、PostgreSQL、SQL Server）都不允许直接传递参数——这不是配置问题，而是语法和执行模型层面的硬性限制。
SQL Server 触发器为什么不能传参
触发器由引擎自动调用，没有调用入口点，因此无法像存储过程那样声明 @param 或接收外部值。它只能通过系统临时表 INSERTED 和 DELETED 访问变更数据，除此之外没有任何输入通道。
- 试图在
CREATE TRIGGER语句里写WITH (param = 'value')或类似结构，会直接报错Incorrect syntax near -
INSTEAD OF和AFTER触发器都受此限制，视图上的触发器也不例外 - 哪怕封装成存储过程再从触发器里
EXEC，也无法把应用层变量带进去——触发器上下文完全隔离
PostgreSQL 的 TG_ARGV 是什么
PostgreSQL 提供了 TG_ARGV 这个只读数组，但它不是“传参”，而是定义触发器时在 CREATE TRIGGER 语句末尾硬编码的字符串列表，例如：
CREATE TRIGGER t_log AFTER INSERT ON orders
FOR EACH ROW
EXECUTE FUNCTION log_action('orders', 'insert');
函数体内通过 TG_ARGV[0]、TG_ARGV[1] 获取，但必须手动类型转换且长度校验：
-
TG_ARGV是text[]类型，即使你写'123'，取出来也是字符串，需用CAST(TG_ARGV[0] AS INTEGER) - 索引越界会报错，必须先检查
array_length(TG_ARGV, 1) - 它只在触发器定义时固定，运行时无法动态改变——不是运行期传参，只是配置复用
MySQL 怎么绕过无参限制
MySQL 连 TG_ARGV 都没有，唯一能跨会话影响触发器行为的方式是会话变量或配置表：
- 设置开关：
SET @trigger_skip_audit = 1;，触发器内用IF @trigger_skip_audit IS NOT NULL THEN ... - 更健壮的做法是建
trigger_config表，存table_name、trigger_name、enabled字段，触发器里用SELECT enabled INTO @enabled FROM trigger_config WHERE ... - 绝对不要在触发器里调用含
SELECT的自定义函数——MySQL 明确禁止触发器中执行查询类函数（除非声明为READS SQL DATA，但极易引发死锁或权限错误） - 全局变量
@@global.xxx对触发器不可见，只能用@@session.xxx或用户变量
真正需要参数化逻辑时该选什么
如果业务本质要求“按条件动态控制行为”，触发器不是合适载体。优先考虑替代方案：
- 用存储过程封装完整操作：把参数、校验、主表写入、关联表写入全包进来，触发器退化为仅做原子级日志或简单约束
- 应用层预计算：比如分表路由、租户隔离、状态机跳转，都在代码里算好目标表名或字段值，再发确定性 SQL
- 代理层分流：ShardingSphere-Proxy 或 Vitess 可解析 SQL 并按规则重写，触发器只保留轻量审计逻辑
- 视图场景别硬扛：SQL 视图不支持参数，改用 SQL Server 的内联表值函数（
RETURNS TABLE）或 PostgreSQL 的RETURNS TABLE()函数，它们才真正支持参数调用
最容易被忽略的是：触发器里的 BEFORE 和 AFTER 阶段对“依赖新生成 ID”的逻辑有根本冲突——BEFORE 能改 NEW 但拿不到自增 ID，AFTER 有 ID 却不能改 NEW。这种场景下，参数化需求几乎必然要移出触发器。
