可以，但必须已赋值；触发器运行在当前会话上下文中，可直接读取已设置的@变量，未赋值则返回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 默认不区分大小写，但某些配置下（如
lower_case_table_names=1）可能影响变量名解析，建议统一小写 - 触发器里用了
SELECT ... INTO @var但没加WHERE或结果为空——@var会被设为NULL，后续判断失效；应先SELECT COUNT(*)或用IFNULL()包裹
替代方案：为什么有时该避免依赖 @ 变量
靠 @ 变量传参本质是“隐式传参”，容易导致逻辑脆弱、调试困难、并发不安全。
- 多语句批量插入时，每个
INSERT行触发一次触发器，但@变量只有一份，无法区分各行上下文 - 如果业务层用连接池，同一物理连接被多个请求复用，前一个请求设的
@xxx可能污染后一个请求的触发器行为 - 更可靠的做法是：把必要上下文塞进插入数据本身（如加
created_by字段），再在触发器中用NEW.created_by访问
真正需要动态开关触发器逻辑时，@disable_triggers 这类标记变量仍是最轻量的解法，但务必配以清晰的文档说明其生命周期和使用约束。
