频繁调用udf在where子句中必然导致全表扫描、执行计划不可预测及性能断崖式下降，因其默认not deterministic，优化器无法缓存或下推，且函数索引仅支持完全匹配表达式，预计算或生成列才是可靠替代方案。

直接说结论：**频繁调用自定义函数（UDF）在 WHERE 子句中，几乎必然导致全表扫描、执行计划不可预测、且性能断崖式下降**。这不是“可能慢”，而是设计机制决定的硬伤。

MySQL 为什么默认把 UDF 当作 NOT DETERMINISTIC

即使你的自定义函数逻辑上纯计算、无副作用（比如 my_trim() 只是去空格），MySQL 仍默认将其标记为 NOT DETERMINISTIC。这意味着优化器不敢缓存结果、不敢下推、不敢重排执行顺序——它只能保守地对每一行都重新调用一次函数。

常见后果：

• EXPLAIN 显示 type=ALL 或 key=NULL，哪怕字段上有索引
• Rows_examined 接近总行数，而 Rows_sent 可能只有几条
• 函数内部若有 IO、正则、循环，单次调用耗时几十毫秒，百万行就是几十秒

DETERMINISTIC 声明不是万能加速器

你加了 DETERMINISTIC 关键字，只是告诉优化器“这个函数输出只取决于输入”，但不等于“它快”或“能走索引”。

关键限制：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 函数体内不能调用 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 的编译、加载、权限校验本身就有开销。在高并发场景下，函数句柄争用可能成为瓶颈，这比函数逻辑慢更难排查。