MySQL自定义函数无法安全执行动态SQL，因其不支持预编译占位符和PREPARE/EXECUTE，且官方限定该能力仅存于存储过程；涉及元数据、条件拼接、排序字段等动态逻辑必须移至应用层，通过白名单+预处理语句实现安全控制。
MySQL 自定义函数里根本不能安全地动态执行 SQL——这不是配置问题，是语法和执行模型的硬性限制。所有试图在 CREATE FUNCTION 里拼接、转义、QUOTE() 或 EXECUTE 的做法，都只是把漏洞藏得更深，而不是堵住它。
为什么 MySQL 函数无法做参数化查询？
因为函数体不支持预编译占位符（如 ? 或 :name），也不允许调用 PREPARE/EXECUTE ——即便你把它包进用户变量，变量值若来自外部输入，EXECUTE 仍会原样展开执行。官方文档明确将该能力限定在存储过程内，且对动态 SQL 字符串来源有强约束。
常见错误包括：
- 用
REPLACE(input, "'", "''")手动“转义”，但漏掉\、%、_、JSON 路径分隔符等上下文敏感字符 - 依赖
QUOTE()返回带单引号的字符串（如'admin'' OR 1=1'），一旦被拼到未加引号的上下文（如ORDER BY <field>），直接失效 - 用
CAST(input AS UNSIGNED)做类型校验，但CONCAT('SELECT * FROM t WHERE id = ', id_param)在 CAST 前就已拼完，静默截断无意义
哪些逻辑必须从函数里移出去？
凡涉及以下任意一项，都不该放在自定义函数中：
- 表名、列名、索引名等元数据（如
search_by(field VARCHAR(64), val VARCHAR(255))） - WHERE 条件片段（如拼
"status = '" + status + "' AND type IN (" + types + ")"） - 排序字段或方向（
ORDER BY <user_input> DESC） - 分页偏移或 LIMIT 参数（除非确定为纯整数且经
CAST(... AS SIGNED)+ 范围校验）
这些必须交由应用层控制：先查白名单确认 field 是 ['email', 'created_at', 'status'] 之一，再用 PDO/PreparedStatement 构造 SELECT * FROM users WHERE email LIKE ?。
如果真没法重构遗留函数，怎么降级防护？
仅限无法迁移、又必须保留动态 SQL 的极少数场景。需同时满足以下全部条件：
- 输入值经严格白名单校验（如枚举值映射到固定 SQL 片段：
IF mode = 'recent' THEN SET sql_part = 'ORDER BY created_at DESC LIMIT 10';） - 所有拼接操作只使用常量或内部计算值，禁止任何用户直传参数参与
CONCAT - 函数返回结果仅为字符串（非执行结果），由调用方再用存储过程封装
PREPARE/EXECUTE，且该存储过程的输入必须是清洗后的变量 - 数据库账号权限收紧到仅允许 SELECT，禁用
FILE、EXECUTE、PROCESS等高危权限
注意：DELIMITER $$ CREATE FUNCTION safe_trim_suffix(s TEXT, suffix TEXT) RETURNS TEXT 这类纯字符串操作可以保留——只要 suffix 不参与 SQL 执行，就不构成注入面。
最易被忽略的一点：函数内没有调用栈、没有日志、没有报错回显，一旦出问题，你连它在哪一行拼错了都看不到。把动态逻辑外移到应用层，不是增加复杂度，而是把不可观测的黑盒，换成可打点、可拦截、可审计的明路径。
