自定义函数无法走查询优化器路径，因其不能参与执行计划优化、索引下推或批量处理，且需每次调用校验权限与特性，导致全表扫描、高CPU开销及性能断崖式下降。
自定义函数无法走查询优化器路径
MySQL 对 SUM、COUNT、DATE_ADD 这类内置函数的处理，是在解析阶段就深度绑定执行引擎的底层逻辑——它们直接映射到 C 层的高效实现，甚至能被优化器提前折叠（constant folding）或下推到存储引擎层。而自定义函数（无论是 SQL 函数还是 UDF）必须在每行数据上「调用—返回」，无法参与执行计划生成阶段的任何优化，比如索引下推、谓词下推、聚合下压等。
常见错误现象：WHERE my_date_func(created_at) > '2023-01-01' 会导致全表扫描，即使 created_at 有索引；因为函数包裹后，优化器无法识别原始字段的可索引性。
- SQL 自定义函数：每次调用都触发一次 SQL 解析+执行上下文切换，开销远高于原生函数的纯 C 调用
- UDF（C 语言编写）：虽比 SQL 函数快，但仍需跨语言边界（MySQL server → C runtime），且无法利用向量化执行或 SIMD 指令
- 所有自定义函数都无法被 MySQL 8.0+ 的直方图统计信息用于代价估算，容易导致优化器选错执行路径
函数体执行缺乏内联与批量处理能力
原生函数如 UPPER() 或 JSON_EXTRACT() 在处理结果集时，往往以向量方式批量处理整列数据，内部使用内存连续读取和分支预测优化。而自定义函数（尤其是 SQL 函数）是逐行解释执行的，每行都要重新进入 BEGIN…END 块、做变量声明/赋值、执行 RETURN，没有循环展开、无 JIT 编译、无批处理缓冲。
使用场景举例：对 100 万行执行 SELECT my_trim_func(name) FROM users，SQL 函数会调用 100 万次；而原生 TRIM() 是单次指令批量完成。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- SQL 函数中避免
SELECT … INTO或子查询，这类操作会引发嵌套执行，放大逐行开销 - UDF 若涉及系统调用（如
fopen()、网络请求），性能会断崖式下跌，且可能引发连接阻塞 - MySQL 8.4 的
VECTOR类型函数（如DOT_PRODUCT）已支持向量化计算，但自定义 UDF 仍只能单向量单调用
权限与安全模型带来额外检查开销
MySQL 对自定义函数的每次调用都会校验 EXECUTE 权限，并检查函数是否被标记为 DETERMINISTIC / NO SQL 等特性——这些元信息在每次调用前都要从数据字典中读取并验证。原生函数不经过这套流程。
容易踩的坑：CREATE FUNCTION f() RETURNS INT NO SQL DETERMINISTIC 中漏写 DETERMINISTIC，会导致函数被默认视为 NOT DETERMINISTIC，从而禁止在某些上下文中使用（如索引表达式、复制过滤规则），还可能触发额外的事务一致性检查。
- 非
DETERMINISTIC函数无法用于函数索引（MySQL 8.0.13+） - 若函数声明为
READS SQL DATA，还会触发额外的只读事务上下文初始化 - UDF 加载时若未用
mysql_install_plugin正确注册，后续每次调用都可能触发插件重加载检查
版本与配置对 UDF 性能影响显著
UDF 的实际性能高度依赖 MySQL 版本和编译选项。例如：MySQL 5.7 默认禁用 UDF 动态加载（secure_file_priv 和 plugin_dir 权限限制严格），而 8.0.23+ 引入了 UDF 沙箱机制，默认限制文件 I/O 和网络访问——这些防护措施会增加每次调用的 syscall 开销。
性能影响示例：一个简单字符串哈希 UDF，在 MySQL 5.7 上平均耗时 0.8μs/次，在 8.4 上因新增的沙箱检查可能升至 2.3μs/次，差距近 3 倍。
- 确认 UDF 是否启用沙箱：
SELECT @@udf_implementation_mode;（8.4 新增变量） - 生产环境慎用
root权限加载 UDF，否则可能绕过沙箱限制，带来安全隐患 - 避免在高并发 OLTP 场景中将 UDF 用于 WHERE 或 JOIN 条件，极易成为 CPU 瓶颈点
