自定义函数在WHERE中一用就变慢，因MySQL默认标记为NOT DETERMINISTIC，导致全表扫描、执行计划不可预测及每行重复调用；DETERMINISTIC声明不解决性能问题，函数索引仅支持完全匹配；可靠替代是预计算字段或生成列+索引。
为什么自定义函数在WHERE里一用就变慢
因为MySQL默认把所有自定义函数（UDF）标记为NOT DETERMINISTIC，优化器不敢缓存、不敢下推、不敢重排执行顺序——只能对每一行都重新调用一次。哪怕你的my_trim()只是去空格，也逃不过全表扫描的命运。
常见现象：EXPLAIN显示type=ALL或key=NULL，Rows_examined接近总行数，而Rows_sent可能只有几条。更隐蔽的是：如果查询带ORDER BY my_func(col)或GROUP BY my_func(col)，该函数可能被调用2–3次/行（WHERE、临时表构建、排序各一次），且完全不共享结果。
DETERMINISTIC声明能解决问题吗
加DETERMINISTIC只是告诉优化器“输出只取决于输入”，不是加速开关。它不自动建索引，也不保证走索引，更不解决重复调用问题。
- 声明无效的典型情况：函数体内用了
NOW()、RAND()、UUID()、SYSDATE()等非确定性函数 - 即使声明成功，MySQL 8.0.13+才支持函数索引，语法必须严格：
CREATE INDEX idx_foo ON t ((my_func(col)))（注意双括号） - 函数索引只对**完全匹配表达式**生效：
WHERE my_func(col) = 'x'可命中；WHERE my_func(col) LIKE 'x%'直接失效
真正有效的替代方案有哪些
别把UDF当SQL里的工具函数用。它的定位是C/SQL胶水，不是基础设施。可靠路径只有两条：
- 写入时预计算：新增
clean_name VARCHAR(255)字段，在INSERT/UPDATE时就存好my_trim(name)结果，再对这个字段建普通索引 - 用生成列（Generated Column）+ 存储索引：
ALTER TABLE t ADD COLUMN name_clean VARCHAR(255) AS (my_trim(name)) STORED，然后CREATE INDEX idx_name_clean ON t(name_clean)
这两条路径都能让WHERE条件回归到普通字段比较，索引立即生效，且无跨阶段重复调用风险。
哪些场景仍不得不调用UDF
极少数情况绕不开，比如实时脱敏、动态权限校验、外部服务回调等。此时必须接受性能代价，并做硬性约束：
- 确保UDF逻辑极轻量：禁用IO、禁用正则、禁用循环；纯数学/字符串操作控制在微秒级
- 绝不让它出现在
ORDER BY或GROUP BY中——否则调用次数翻倍 - 配合
WHERE前置强过滤：先用高选择性索引字段（如status = 'active' AND created_at > '2026-01-01'）把数据量压到千行以内，再对小结果集调用UDF
最常被忽略的一点：函数索引和生成列都要求MySQL ≥ 8.0.13，低于这个版本只能靠预计算字段+普通索引，否则没有安全出路。
