频繁调用UDF在WHERE子句中必然导致全表扫描、执行计划不可预测及性能断崖式下降，因其默认NOT DETERMINISTIC，优化器无法缓存或下推，且函数索引仅支持完全匹配表达式，预计算或生成列才是可靠替代方案。
MySQL 为什么默认把 UDF 当作 NOT DETERMINISTIC
即使你的自定义函数逻辑上纯计算、无副作用（比如 my_trim() 只是去空格），MySQL 仍默认将其标记为 NOT DETERMINISTIC。这意味着优化器不敢缓存结果、不敢下推、不敢重排执行顺序——它只能保守地对每一行都重新调用一次函数。
常见后果：
- EXPLAIN 显示
type=ALL或key=NULL，哪怕字段上有索引 - Rows_examined 接近总行数，而 Rows_sent 可能只有几条
- 函数内部若有 IO、正则、循环，单次调用耗时几十毫秒，百万行就是几十秒
DETERMINISTIC 声明不是万能加速器
你加了 DETERMINISTIC 关键字，只是告诉优化器“这个函数输出只取决于输入”，但不等于“它快”或“能走索引”。
关键限制：
- 函数体内不能调用
NOW()、RAND()、UUID()、SYSDATE()等非确定性函数，否则声明无效 - 即使声明成功，MySQL 也**不会**自动为该函数建索引——你得手动建函数索引（MySQL 8.0.13+），且语法严格：
CREATE INDEX idx_foo ON t ((my_func(col)))（注意双括号） - 函数索引只对**完全匹配表达式**生效：
WHERE my_func(col) = 'x'可命中；WHERE my_func(col) LIKE 'x%'不行
比“能不能走索引”更隐蔽的坑：临时表与排序阶段重复调用
当查询涉及 ORDER BY、GROUP BY 或子查询时，UDF 可能在多个阶段被反复调用：
- WHERE 过滤阶段调一次
- 构建临时表时再调一次（尤其
SELECT my_func(col)+GROUP BY my_func(col)） - 排序时又调一次（如果
ORDER BY my_func(col)）
没有缓存机制，也没有跨阶段复用，每行调用三次是常态。而内置函数如 UPPER() 在这些阶段有内部优化，UDF 没有。
真正可行的替代路径
别把 UDF 当“SQL 里的工具函数”来用。它本质是 C/SQL 层的胶带，不是基础设施：
- 写入时预计算：新增
clean_name VARCHAR(255)字段，INSERT/UPDATE 时就存好my_trim(name)结果，然后对这个字段建普通索引 - 用生成列（Generated Column）+ 存储索引：
ADD COLUMN name_clean VARCHAR(255) AS (my_trim(name)) STORED，再CREATE INDEX idx_name_clean ON t(name_clean) - 复杂逻辑拆到应用层：比如地址标准化、模糊匹配，交给 Python/Go 处理，数据库只存标准格式
最常被忽略的一点：UDF 的编译、加载、权限校验本身就有开销。在高并发场景下，函数句柄争用可能成为瓶颈，这比函数逻辑慢更难排查。
