MySQL触发器中禁止使用PREPARE等动态SQL，因引擎层硬性限制而非权限或配置问题；即使封装在存储过程中被CALL，也会静态扫描调用链并报ERROR 1336，唯一可行方案是硬编码IF分支或移至应用层/代理层处理。
MySQL触发器里写 PREPARE 一定会报错，不是配置没开、权限不够，而是引擎层硬性禁止——连带所有依赖它的方案（比如CALL含PREPARE的存储过程）全都会失败。
触发器中调用PREPARE直接报ERROR 1336
错误信息固定为：ERROR 1336 (0A000): Dynamic SQL is not allowed in stored function or trigger。这不是运行时检查，是MySQL在解析触发器定义时就静态拦截的。哪怕你把PREPARE封装进一个独立存储过程，再从触发器里CALL它，照样报错。
根本原因在于：触发器执行必须满足原子性与可回滚性，而PREPARE需要动态解析SQL、生成执行计划、分配资源，这会破坏语句上下文的确定性。官方文档明确将其列为「not allowed」，跟log_bin_trust_function_creators或用户权限完全无关。
- 所有含
PREPARE/EXECUTE/DEALLOCATE PREPARE的语句，在触发器体或其调用链任意一层出现，都会被拒绝 -
SHOW CREATE TRIGGER能看到触发器定义，但无法反映调用链是否隐含动态SQL - 错误发生在触发器被激活前的校验阶段，不是
CALL那一刻才崩
为什么把PREPARE挪到存储过程里也行不通
MySQL会对整个调用链做静态扫描：只要触发器可能最终走到含PREPARE的路径，就会提前拒绝。即使那个存储过程单独CALL能成功，一旦被触发器调用，就触发校验失败。
更麻烦的是，这种限制还叠加了另一层：MySQL 8.0.23+ 对“stashed”（嵌套调用）过程加了额外限制——如果存储过程本身是被其他过程CALL的（非顶层），那它内部的PREPARE还会额外触发Operation not allowed in stashed procedure错误。
- 不存在“绕过触发器直接调用”的中间态；触发器就是执行链的起点，所有下游都受牵连
- 试图用
IF条件控制是否执行PREPARE也没用，静态扫描不看分支逻辑，只看语句是否存在 - 连
SELECT ... INTO @sql再PREPARE这种间接方式，同样被拦
真正能落地的替代方案只有两种
硬编码分支和中转表+定时任务，是目前唯一被验证可行的路径。前者适合分表数量可控（如
- 硬编码方案：用
IF NEW.point_id = 93 THEN INSERT INTO point_93 (...) VALUES (...);逐个枚举，表名和字段都写死，不能拼接 - 中转表方案：触发器只往
sync_queue写一行记录（含目标表名、原始数据JSON等），再由外部定时任务CALL sync_from_queue()来执行PREPARE插入 - 注意
sync_from_queue()不能操作原触发表（比如order），否则会触发ERROR 1442（不能更新正在被触发的表）
容易被忽略的兼容性细节
即便选了中转表方案，也要小心MySQL版本差异带来的行为变化。比如STRICT_TRANS_TABLES模式下，UPDATE语句若未实际修改字段值，整个语句（含触发器）会被跳过；而NO_UNSIGNED_SUBTRACTION可能让数值计算异常，导致中转表里存错sync_to表名。
还有，PREPARE语句本身不支持多语句、不支持TIME精度秒后小数位、对ZEROFILL整数的处理也不稳定——这些坑不会在触发器里暴露，但会在后续的sync_from_queue()中突然冒出来。
