MySQL硬性禁止在函数和触发器中使用动态SQL，因其破坏确定性与事务一致性；唯一合规方案是改用存储过程配合OUT参数，并确保调用链不经过函数或触发器。
ERROR 1336 (0A000): Dynamic SQL is not allowed in stored function or trigger 这个错误不是配置问题，也不是权限或语法写错了——是 MySQL 硬性禁止的。存储函数（CREATE FUNCTION）和触发器（CREATE TRIGGER）里压根不支持 PREPARE/EXECUTE 这套动态 SQL 流程。
为什么函数里不能用 PREPARE/EXECUTE？
MySQL 把函数设计成「纯计算单元」：它必须可预测、可重复、不能有副作用（比如改表、删数据、开游标）。而 PREPARE 和 EXECUTE 可能触发 DDL/DML，破坏事务一致性与查询优化器的推断能力。所以从语法层直接拦掉，连解析都不让过。
报错时别试绕过，先确认是不是函数
- 检查你写的对象类型：
CREATE FUNCTION≠CREATE PROCEDURE—— 后者允许动态 SQL，前者绝对不行 - 哪怕只写了一行
SET @sql = 'SELECT 1'; PREPARE stmt FROM @sql;，函数定义就会失败 - 触发器同理，
BEFORE INSERT或AFTER UPDATE中也不能出现PREPARE
替代方案：用存储过程 + OUT 参数模拟函数行为
如果你真需要「根据输入拼 SQL 并返回结果」，只能换结构：
- 把逻辑挪到
CREATE PROCEDURE里，用OUT或INOUT参数传回计算值 - 调用方改成
CALL proc_name('table_a', @result); SELECT @result; - 注意：过程里仍要遵守动态 SQL 规则——
@sql必须是用户变量、表名列名加反引号、每次DEALLOCATE PREPARE stmt
容易被忽略的兼容边界
哪怕你把函数改成过程，如果调用链里上层是函数（比如视图定义里用了自定义函数），那这个过程也进不去——MySQL 会层层校验执行上下文。最稳妥的做法是：凡涉及拼接表名/字段名/条件的逻辑，一律放在过程里，且确保调用路径中不经过函数或触发器。
