MySQL触发器中禁止使用PREPARE、EXECUTE等动态SQL，因引擎层硬性限制，与权限或配置无关；分表路由需硬编码IF分支或移至应用层/代理层实现。
MySQL触发器里根本不能用 PREPARE、EXECUTE 或任何动态拼接 SQL 的方式——不是配置没开、不是权限不够，是引擎层硬性禁止。 所有试图在触发器体内调用存储过程再执行动态 SQL 的方案，最终都会报 ERROR 1336 (0A000): Dynamic SQL is not allowed in stored function or trigger。绕不开，只能换思路。
为什么触发器里写 PREPARE 一定会失败
MySQL 在触发器执行时锁定语句上下文，禁止任何会改变执行计划或元数据的操作。PREPARE 属于运行时编译，需要解析、生成执行计划，这与触发器的原子性、可回滚性设计冲突。官方文档明确归类为「not allowed」，和权限无关，也和 log_bin_trust_function_creators 无关。
- 哪怕把
PREPARE放进存储过程，再从触发器CALL它，照样报错 —— 触发器调用栈内所有上下文都受同一限制 -
CREATE EVENT、CREATE TABLE、DROP TABLE等 DDL 操作在触发器中一律禁止 - 连
SELECT ... INTO @var后拼字符串再EXECUTE这种常见套路，也会在EXECUTE那一刻直接中断
分表路由必须显式写死表名
想按时间、ID 尾号、租户 ID 自动写入不同分表？触发器里只能靠 IF/ELSEIF 列出所有可能目标表，逐一判断后 INSERT INTO table_xxx。
- 比如按
new.id % 10路由：必须手写 10 个INSERT INTO keyindex_0~keyindex_9分支 - 表数量超过 20 个时，维护成本陡增；新增分表要改触发器、重新
CREATE TRIGGER - 不能用
CONCAT('keyindex_', new.id % 10)拼表名 —— 触发器不支持标识符动态化 - 字段列表必须完全一致，否则
INSERT会因列数/类型不匹配失败
真正可行的替代方案只有两种
硬编码分支太重？那得把逻辑移出数据库。触发器只做轻量、确定性动作，其余交给上层。
- 应用层分表：插入前计算目标表名（如
t_log_202604），生成对应INSERT语句直连执行 —— 最灵活，可控性强 - 代理层路由：用
MyCat、ShardingSphere-Proxy或Vitess做 SQL 解析与自动分发，触发器退化为纯业务校验用途 - 别碰「触发器 + 存储过程 + 动态 SQL」组合：实测无效，且容易误以为“只要存储过程开了就能用”，浪费调试时间
最常被忽略的一点：触发器里的 BEFORE INSERT 和 AFTER INSERT 对分表影响极大。如果要在分表前修改 NEW 字段（比如补全时间分区字段），必须用 BEFORE；但若分表逻辑依赖主表自增 ID（NEW.id），就得用 AFTER —— 可 AFTER 又无法改 NEW。这种矛盾本身就在提醒你：分表不该压给触发器。
