mysql函数中禁止prepare/execute是内核级硬性限制，解析阶段即报error 1336；动态sql破坏确定性、主从一致性及查询优化，合法替代方案为存储过程+白名单校验。
MySQL自定义函数中压根不允许 PREPARE/EXECUTE，这不是语法写错或权限问题，是内核级硬性限制。
ERROR 1336 报错不是配置没开，而是语法层直接拒绝
只要函数定义里出现 PREPARE、EXECUTE 或 DEALLOCATE PREPARE，MySQL 在解析阶段就报 ERROR 1336 (0A000): Dynamic SQL is not allowed in stored function or trigger。连 SET @sql = 'SELECT 1'; PREPARE stmt FROM @sql; 这种单行也会失败。
- 触发器同理，哪怕只是调用一个含
PREPARE的存储过程，也会被静态扫描拦截 - 不是运行时检查，所以加
IF判断分支也绕不过去 -
log_bin_trust_function_creators、用户权限、SQL mode 全部无关
函数必须是“确定性纯计算单元”，动态SQL破坏这个前提
MySQL 要求函数在相同输入下必须返回相同结果，且不能有副作用（比如改数据、开游标、访问表）。而 PREPARE 可能执行任意 DML/DDL，导致：
- 主从复制不一致：binlog 记录的是函数调用，不是实际执行的动态语句
- 查询优化器失效：无法预判执行路径、资源消耗、是否可缓存
- 事务一致性受损：函数可能被嵌入
SELECT中多次调用，但动态 SQL 的执行状态不可控
想拼表名/字段名？只能换结构，别在函数里硬扛
常见需求如 “根据参数查不同分区表” 或 “按字段名动态过滤”，合法路径只有一条：改用存储过程 + OUT 参数。
- 表名、列名仍需字符串拼接，但必须白名单校验：
@table_name REGEXP '^[a-zA-Z_][a-zA-Z0-9_]*$' -
USING只支持值（?），不支持标识符；拼接部分要手动包裹反引号：CONCAT('SELECT * FROM `', @table_name, '`') - 调用方必须用
CALL proc_name(?, @out); SELECT @out;，不能像函数那样嵌入SELECT表达式 - 如果上层是视图或另一个函数，这条调用链依然会断——MySQL 会逐层校验上下文
GROUP_CONCAT 截断、语句名冲突、注入漏洞，全是连带雷区
就算你成功把逻辑挪到存储过程里，还有几个容易被忽略的坑：
-
group_concat_max_len默认 1024，拼出的 SQL 超长会被砍掉，导致PREPARE时报You have an error in your SQL syntax - 重复
PREPARE stmt FROM ...不释放会触发ERROR 1243: Unknown prepared statement handler；建议用DROP PREPARE IF EXISTS stmt（MySQL 8.0.13+） -
QUOTE()或REPLACE(..., "'", "''")不能防注入——它对ORDER BY字段、JSON_EXTRACT路径、正则表达式等完全无效
最常被跳过的点：函数里任何涉及外部输入的字符串拼接，只要最终导向 SQL 执行，就等于把注入入口直接暴露给调用方。安全边界不在函数体内，而在调用它的那一层——要么应用层白名单+预编译，要么数据库层彻底放弃函数，改走过程+严格校验。
