MySQL触发器中禁止使用PREPARE语句，因引擎层在CREATE时静态扫描即拦截，报ERROR 1336；根本原因在于触发器需保证原子性与可回滚性，而PREPARE破坏执行上下文确定性，官方明确列为not allowed，与权限、配置无关。
MySQL 在触发器中直接拒绝 PREPARE，不是配置没开、权限不够，也不是你写法有误——是引擎层在创建触发器时就静态扫描并拦截，报错 ERROR 1336 (0A000): Dynamic SQL is not allowed in stored function or trigger。
触发器里写 PREPARE 为什么连 CREATE 都失败？
MySQL 解析器在执行 CREATE TRIGGER 时，不等运行，只看语句文本：只要发现 PREPARE、EXECUTE 或 DEALLOCATE PREPARE，立刻终止创建。这不是运行时检查，更不是权限校验。
- 哪怕只有一行
PREPARE stmt FROM @sql;，触发器定义就失败 -
SELECT ... INTO @sql; PREPARE stmt FROM @sql;同样被拦，不看变量是否为空或分支是否可达 - 把
PREPARE封装进存储过程再CALL，照样失败——MySQL 会穿透调用链做全路径静态分析
为什么存储过程能用 PREPARE，触发器却不行？
根本矛盾在于执行上下文的确定性要求不同：
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 存储过程是显式调用（
CALL proc()），会话上下文可控，资源可清理 - 触发器是隐式自动触发，必须和原 SQL 共享事务、锁、回滚段；而
PREPARE需要运行时解析、生成执行计划、分配语句句柄，破坏原子性和可回滚性 - 官方文档明确将
PREPARE列为触发器/函数中的not allowed操作，与log_bin_trust_function_creators或用户权限完全无关
哪些“看起来像动态”的写法其实是安全的？
只要不涉及运行时 SQL 解析，以下操作在触发器内完全合法：
-
INSERT INTO orders_202409 SELECT * FROM orders WHERE id = NEW.id;—— 表名、字段全静态 -
SET @val = NEW.amount * 0.05; INSERT INTO tax_log (tax) VALUES (@val);—— 变量赋值 + 静态语句 -
INSERT INTO log_table (msg) VALUES (CASE WHEN NEW.status = 'paid' THEN 'OK' ELSE 'pending' END);—— 条件表达式不触发动态解析
硬编码 IF 分支是唯一合规替代方案
分表路由这类需求，只能靠显式枚举：
- 表名不能拼接，必须写死：
INSERT INTO keyindex_0、INSERT INTO keyindex_1 - 字段不能用
*，必须逐个列出：INSERT INTO keyindex_0 (id, key_name, ts) VALUES (...) - 若按
NEW.id % 16路由，就得手写 16 个IF ... ELSEIF分支 - 新增分表时，必须
DROP TRIGGER再CREATE TRIGGER，无法热更新
真正卡住的从来不是“怎么加权限”，而是 MySQL 根本不允许触发器拥有运行时 SQL 编译能力——这个限制从 5.7 到 8.0 始终未变，且没有绕过路径。
