MySQL触发器不能绑定到TEMPORARY表，CREATE TRIGGER直接报ERROR 1352，因临时表无持久元数据且不存于系统表；触发器内也不允许CREATE TEMPORARY TABLE，属DDL禁令，会报ERROR 1356或1419。
MySQL触发器不能绑定到TEMPORARY表：CREATE TRIGGER直接报错
MySQL在解析CREATE TRIGGER语句时就拒绝绑定到临时表，根本不会等到执行阶段。错误信息固定为：ERROR 1352 (HY000): Trigger cannot be created on a TEMPORARY table。这不是权限问题，也不是语法写错，而是引擎层的硬性拦截。
原因很直接：临时表生命周期只限于当前会话，而触发器是数据库对象，需持久化存储在系统表（如mysql.triggers）中。两者元数据管理机制冲突——临时表没有CREATE_TIME、DEFINER等触发器依赖的字段，也无法被SHOW TRIGGERS或INFORMATION_SCHEMA.TRIGGERS查询到。
- 哪怕你用
CREATE TEMPORARY TABLE t1 (...)建好表，再立刻执行CREATE TRIGGER tr ON t1 ...，照样报1352 -
IF NOT EXISTS或TRY...CATCH类结构完全无效——错误发生在语法解析/权限校验阶段，不进执行引擎 - 试图跨库引用也不行：
CREATE TRIGGER tr ON tempdb.t1仍会报ERROR 1146: Table 'tempdb.t1' doesn't exist，因为临时表不在tempdbschema下，它压根不进数据字典
为什么不能在触发器里CREATE TEMPORARY TABLE
触发器体（trigger_body）中禁止任何DDL语句，CREATE TEMPORARY TABLE属于DDL，执行时抛出ERROR 1356 (HY000): View's SELECT contains a subquery in the FROM clause或更常见的ERROR 1419 (HY000): You do not have the SUPER privilege and binary logging is enabled（当binlog开启时）。根本原因在于：MySQL触发器设计契约明确排除结构变更操作。
- 临时表创建会修改
tempdb的元数据，影响复制一致性；主从同步要求所有节点执行相同逻辑，而临时表无法保证从库存在或结构一致 - 即使关闭binlog，
CREATE TEMPORARY TABLE在触发器中仍被语法解析器标记为非法，报错ERROR 1357 (HY000): Can't declare variable inside a trigger（误报，实际是DDL拦截） - 用存储过程封装
CREATE TEMPORARY TABLE再从触发器里CALL，依然失败——调用链不改变DDL禁令，错误提前到触发器定义阶段
替代方案：用INSERTED/DELETED语义模拟临时表行为
真正需要的往往不是“建一张临时表”，而是“暂存当前行数据做计算”。MySQL提供NEW和OLD伪记录，它们就是轻量级、零开销的“内存临时表”。
-
BEFORE INSERT：用NEW.col_name读取待插入值，可直接赋值修改（如自动填充created_at） -
AFTER UPDATE：用OLD.col_name和NEW.col_name对比变化，避免SELECT * FROM target_table WHERE id = NEW.id引发ERROR 1442 - 多行聚合需求？改用
INSERT ... SELECT+JOIN子句，在单条语句内完成计算，绕过触发器作用域限制
例如限制薪资不能超部门平均值1.5倍，不要建临时表查均值，直接写：SELECT COALESCE(AVG(salary), 0) * 1.5 FROM employees WHERE dept_id = NEW.dept_id。
容易忽略的关键点：临时表 ≠ 触发器安全区
有人以为“既然临时表只本会话可见，那在触发器里用应该没问题”，这是危险误解。临时表的“会话隔离”对触发器不生效——触发器运行在父SQL事务上下文中，而临时表的生命周期受客户端连接控制，一旦连接中断或显式DROP，后续触发器执行就会因Table doesn't exist失败。更隐蔽的是：在存储过程中创建临时表，再由触发器调用该过程，表虽存在，但NEW/OLD无法插入其中（INSERT INTO #t SELECT NEW.*语法不被支持），强行写会导致ERROR 1327 (42000): Undeclared variable。
