MySQL触发器中禁止执行任何SET语句，包括SET SESSION和SET GLOBAL，解析阶段即拦截，报错ERROR 1305是语法限制所致，并非函数不存在；替代方案为应用层设置变量或用NEW字段赋值。
MySQL触发器里执行 SET SESSION sql_mode = 'STRICT_TRANS_TABLES' 这类语句会直接报错，不是语法写错了，而是 MySQL 在解析阶段就拦截了——触发器根本不能修改任何系统变量。
触发器内 SET 语句只允许改会话级变量？错，连 SESSION 变量都不行
很多人误以为只要变量支持 SET SESSION 就能在触发器里用。实际上，MySQL 对触发器上下文做了硬性限制：所有 SET 语句（无论 SESSION 还是 GLOBAL）都被禁止。哪怕变量本身可动态修改（比如 time_zone），在触发器中写 SET NEW.time_zone = '+08:00' 或 SET SESSION time_zone = '+08:00' 都会触发 ERROR 1305 (42000): FUNCTION xxx does not exist 或更模糊的解析失败。
-
SET是会话级命令，而触发器运行在“语句执行上下文”中，不拥有独立会话生命周期 - MySQL 解析器在构建触发器执行计划时，直接过滤掉所有
SET类操作，不进入权限校验环节 - 即使你用
DEFINER = 'root'@'%'，也绕不过这一层语法拒绝
为什么报错信息看起来像函数不存在？
这不是 bug，是 MySQL 的错误码复用机制。当解析器遇到触发器中非法的 SET 语句时，并不生成专门的错误码，而是退回到通用解析失败路径，最终抛出 ERROR 1305 —— 它本意是“函数未定义”，但被借用来表示“该语法在此上下文不可用”。这种设计让错误日志难以直觉定位问题根源。
- 查
SHOW CREATE TRIGGER看到语法合法，不代表能执行 - 错误日志里不会出现 “SET not allowed in trigger” 这样的提示
- 最可靠验证方式：把触发器里的
SET行单独拿出来，在普通会话中执行，确认它本身是合法的
想动态控制行为，替代方案只有两个
触发器没法改变量，但业务逻辑还得走。可行路径非常有限：
- 把需要依赖变量的行为移到应用层：比如用连接参数指定
sql_mode，或在 ORM 初始化时设置会话变量 - 用
NEW字段做数据级兜底：例如用SET NEW.created_at = NOW()替代依赖sysdate变量的逻辑，本质是把“变量控制”转为“字段赋值”
别试存储过程封装 SET 再从触发器调用——只要过程体里含 SET，调用时一样报错。这是 SQL 层硬约束，不是权限或版本问题。
