mysql 5.7触发器中prepare和execute完全不可用，因引擎层硬性禁止动态sql，静态扫描调用链即拦截，报error 1336；唯一合规方案是硬编码if/elseif分支枚举表名与字段。
PREPARE 和 EXECUTE 在 MySQL 5.7 触发器中根本不可用，不是配置没开、权限不足，而是引擎层硬性禁止。
触发器里写 PREPARE 会直接报错 ERROR 1336
错误信息固定为：ERROR 1336 (0A000): Dynamic SQL is not allowed in stored function or trigger。这不是运行时检查，是 MySQL 在解析触发器定义时就静态扫描并拦截的——哪怕你只写了 PREPARE stmt FROM @sql 这一行，连创建触发器都会失败。
- 即使把
PREPARE封装进一个独立存储过程，再从触发器里CALL它，照样报错：MySQL 会穿透调用链做静态分析，只要路径中可能执行动态 SQL，就拒绝整个触发器 -
SELECT ... INTO @sql; PREPARE stmt FROM @sql;这类间接写法同样被拦，不看分支逻辑，只看语句是否存在 - 连
CONCAT('INSERT INTO ', @table_name)这种字符串拼接本身虽不报错，但后续无法执行，属于无效劳动
为什么引擎层要这么严格？
触发器必须满足原子性与可回滚性，而 PREPARE 需要运行时解析 SQL、生成执行计划、分配资源，这会破坏语句上下文的确定性。官方文档明确将 PREPARE/EXECUTE/DEALLOCATE PREPARE 列为「not allowed」，跟 log_bin_trust_function_creators 或用户权限完全无关。
- DDL 操作（如
CREATE TABLE、DROP TABLE）在触发器中也一律禁止 - 触发器中甚至不能
CREATE TEMPORARY TABLE，因为这是 DDL - 所有试图绕过限制的组合（比如触发器 → 存储过程 →
PREPARE）实测全部无效，且容易误以为“封装一下就能用”，浪费大量调试时间
那分表路由这种需求怎么落地？
唯一合规做法是硬编码 IF/ELSEIF 分支，显式枚举所有目标表名和字段列表。
- 表名不能拼接，必须写死，例如
INSERT INTO keyindex_0、INSERT INTO keyindex_1 - 字段必须一一列出，不能用
*或动态生成列名 - 若按
NEW.id % 10路由，就得手写 10 个IF分支；超过 20 张表时，维护成本陡增，新增分表必须重CREATE TRIGGER - 可配合
INFORMATION_SCHEMA.TABLES在部署前校验所有分支表是否真实存在
哪些操作看起来像动态，其实允许？
以下写法在触发器里是安全的，因为不涉及运行时 SQL 解析：
-
INSERT INTO t1 SELECT * FROM t2 WHERE id = NEW.id—— 表名、字段名全静态 -
SET @x = NEW.field_a; INSERT INTO log_table (val) VALUES (@x)—— 变量赋值 + 静态语句 -
INSERT INTO t (status) VALUES (CASE WHEN NEW.type = 'A' THEN 'active' ELSE 'inactive' END)—— 字段值用表达式计算 - 调用不含动态 SQL 的存储过程（纯
INSERT/UPDATE/SELECT）
真正容易被忽略的一点是：这个限制不是“暂时没实现”，而是 MySQL 整个事务执行模型决定的底层约束。哪怕升级到 MySQL 9.6.0（2026 年新版本），该限制依然存在——它和外键上移、容器适配这些新特性不在同一设计维度上。
