可以，但必须已赋值；触发器运行在当前会话上下文中，可直接读取已设置的@变量，未赋值则返回NULL，且不跨会话、不区分大小写（默认）、不可用于表名等标识符位置。

触发器里能直接用 @var_name 吗？可以，但必须已赋值

能。MySQL 触发器中可以直接引用会话级用户变量（即以 @ 开头的变量），前提是该变量在触发器执行前已被当前会话显式赋值，且未被后续语句覆盖或清空。

触发器本身不创建新会话，它运行在触发它的 SQL 语句所属的同一会话上下文中，因此所有已设的 @ 变量都可见。

• SET @user_id = 123; 执行后，紧接着 INSERT INTO orders ... 触发 AFTER INSERT 触发器，触发器内可直接读 @user_id
• 若触发器在存储过程中被调用，而该过程内未设置 @user_id，外部会话也未设，则触发器中读 @user_id 返回 NULL
• 不要依赖客户端连接池自动复用会话时的变量残留——不同请求可能共享会话，@ 变量值不可控

@@session. 系统变量和 @ 用户变量不能混用

别把 @@session.sql_mode 和 @sql_mode 当成一回事。前者是服务器定义的会话系统变量，后者是用户自定义变量，名字相同也互不影响。

• 触发器中写 SELECT @@session.autocommit; 是合法的，返回当前会话自动提交状态
• 但写 SELECT @autocommit; 是查一个叫 autocommit 的用户变量，和系统变量无关，大概率是 NULL
• 想在触发器里判断是否禁用触发器逻辑，推荐用 @disable_triggers IS NULL 这种明确的用户变量，而不是试图读某个同名系统变量

触发器里读 @ 变量失败的常见原因

不是语法错，而是执行时机或作用域出问题。最常踩的坑就三个：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 变量在另一个会话里设的——@ 变量不跨会话，其他连接设的值对当前触发器完全不可见
• 变量名拼错或大小写不一致——MySQL 默认不区分大小写，但某些配置下（如 lower_case_table_names=1）可能影响变量名解析，建议统一小写
• 触发器里用了 SELECT ... INTO @var 但没加 WHERE 或结果为空——@var 会被设为 NULL，后续判断失效；应先 SELECT COUNT(*) 或用 IFNULL() 包裹

替代方案：为什么有时该避免依赖 @ 变量

靠 @ 变量传参本质是“隐式传参”，容易导致逻辑脆弱、调试困难、并发不安全。

• 多语句批量插入时，每个 INSERT 行触发一次触发器，但 @ 变量只有一份，无法区分各行上下文
• 如果业务层用连接池，同一物理连接被多个请求复用，前一个请求设的 @xxx 可能污染后一个请求的触发器行为
• 更可靠的做法是：把必要上下文塞进插入数据本身（如加 created_by 字段），再在触发器中用 NEW.created_by 访问

真正需要动态开关触发器逻辑时，@disable_triggers 这类标记变量仍是最轻量的解法，但务必配以清晰的文档说明其生命周期和使用约束。