MySQL自定义函数不能用于WHERE条件加速查询，因其默认逐行计算且优化器无法下推或利用索引，即使简单表达式也会导致全表扫描；必须显式声明DETERMINISTIC/NO SQL/READS SQL DATA属性，否则创建失败。
MySQL自定义函数为什么不能用在WHERE条件里加速查询
因为MySQL对FUNCTION的调用默认是「逐行计算」，优化器无法下推、无法利用索引，哪怕函数体只是一行RETURN col + 1，也会让整张表变成全表扫描。
常见错误现象：SELECT * FROM orders WHERE calc_status(order_id) = 'done'，执行计划显示type: ALL，哪怕order_id有主键索引也无济于事。
- 除非函数被标记为
DETERMINISTIC且实际不依赖会变的数据（比如系统时间、用户变量），否则MySQL连是否缓存结果都不敢假设 - 更隐蔽的坑：函数里调了
SELECT或UUID()这类非确定性操作，即使声明了DETERMINISTIC，也可能触发复制异常或执行计划退化 - 替代方案优先考虑生成列（
GENERATED COLUMN）+ 索引，或者把逻辑提到应用层做预计算
CREATE FUNCTION时必须显式声明的三个属性
MySQL强制要求声明DETERMINISTIC、NO SQL或READS SQL DATA，不是可选项——漏写任意一个，CREATE FUNCTION直接报错ERROR 1418。
使用场景取决于函数体内真实行为：
-
NO SQL：函数里完全没SQL语句，比如纯字符串处理（CONCAT、REPLACE）或数学计算（ABS、POW） -
READS SQL DATA：只读表，不修改数据，例如SELECT COUNT(*) FROM ... -
DETERMINISTIC必须和上面二者之一共存，但它的含义是「相同输入永远返回相同输出」，跟是否读写SQL无关；误标会导致从库执行出错或主从不一致
示例：CREATE FUNCTION f_add(a INT, b INT) RETURNS INT NO SQL DETERMINISTIC BEGIN RETURN a + b; END
为什么自定义函数在JOIN中比在SELECT列表里更伤性能
因为JOIN条件里的函数调用会触发「嵌套循环的每一次迭代都执行一次」，而SELECT列表里的函数最多执行N次（N=结果行数）；但JOIN中如果驱动表有1万行，被驱动表有5千行，最坏可能调用5千万次函数。
参数差异很关键：函数如果接受的是常量或连接字段以外的值，MySQL往往无法做任何优化。
- 避免写
ON t1.id = f_hash(t2.code)，应改为提前算好t2.code_hash并建索引 - 如果非要用，确保函数体极轻量（无子查询、无IO、无锁），且输入参数类型与索引字段严格一致（比如
VARCHAR(32)传入CHAR(32)可能隐式转换失效） - MySQL 8.0+支持函数索引，但仅限于
STORED GENERATED COLUMN，不能直接给函数建索引
调试自定义函数时看不到错误堆栈怎么办
MySQL函数内发生错误（比如除零、类型转换失败）默认静默返回NULL，不会中断执行，也不报错——这是最容易被忽略的逻辑黑洞。
真实调试手段只有两个有效路径：
- 在函数开头加
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION SET @last_error = CONCAT('ERR:', MYSQL_ERRNO(), ':', MESSAGE_TEXT);，再用SELECT @last_error查 - 把关键中间值赋给用户变量（如
SET @debug_v = input_val * 2;），然后在调用后立刻SELECT @debug_v观察 - 禁止在生产环境用
SHOW WARNINGS指望捕获函数内警告——它只反映上一条SQL语句，不包含函数内部执行过程
另外注意：SELECT f_bad(1/0)不会报错，但SELECT 1/(0)会——函数把错误吞掉了。
真正卡住人的地方从来不是语法怎么写，而是函数一旦嵌进复杂查询的某个角落，就再也看不出它正在拖慢整个查询，还假装自己什么都没干。
