自定义函数调用开销远高于内联函数，因每次执行需完整上下文切换且优化器不可见，导致无法走索引、易全表扫描；建议用标准sql重写、生成列固化或sys.statement_analysis定位性能瓶颈。
自定义函数调用开销比内联计算高得多
MySQL 每次执行 SELECT my_func(col)，都要完成一次完整上下文切换：保存当前执行栈、加载函数定义、解析参数类型、执行函数体、转换返回值类型、还原上下文。这个过程在每行数据上重复发生，而内联函数（如 YEAR()、UPPER()）是 SQL 引擎原生支持的，直接在执行器中展开，无额外调度成本。
实操建议：
- 用
sys.statement_analysis查看某条慢查询中函数调用的TIMER_WAIT占比，若超过 60%，基本可判定是函数本身拖累 - 对高频字段做计算时，避免在
WHERE或SELECT中反复调用自定义函数，改用生成列（STORED）+索引固化结果 - 非确定性函数（含
NOW()、RAND()、UUID()）无法被优化器缓存或下推，应尽量规避
优化器对自定义函数“不可见”，无法生成高效执行计划
MySQL 查询优化器知道 DATE(create_time) 能走索引范围扫描，但对 my_date_only(create_time) 完全黑盒——它既不能预估选择率，也无法下推条件，更不会尝试索引合并或松散索引扫描。结果就是：明明逻辑等价，WHERE my_date_only(t) = '2024-01-01' 很可能退化为全表扫描。
实操建议：
- 所有用于过滤的函数逻辑，优先用标准 SQL 表达式重写，例如把
WHERE my_month_year(dt) = '2024-01'改成WHERE dt >= '2024-01-01' AND dt - 若必须封装逻辑，用视图（
CREATE VIEW）替代函数，视图可被优化器展开并参与索引选择 - 检查
EXPLAIN输出中key和rows字段：如果用了函数后key变为NULL或rows突增一个数量级，就是优化器放弃索引的明确信号
标量函数逐行执行，无法利用向量化或批量处理能力
MySQL 8.0+ 对内置函数（如 JSON_EXTRACT()、REGEXP_LIKE()）已做向量化加速，但自定义函数仍是纯标量模型：输入一行、输出一行、中间无并行。当处理百万级结果集时，函数调用次数 = 行数 × 函数出现频次，CPU 时间线性增长，且无法被缓冲池或执行缓存复用。
实操建议：
- 对 JSON 字段提取固定路径值，不要用
my_json_get(data, '$.status')，而是建虚拟列：ALTER TABLE t ADD COLUMN status TINYINT AS (JSON_EXTRACT(data, '$.status')) STORED，再对status建索引 - 字符串拼接慎用
CONCAT()封装函数，大字段拼接易触发隐式转换和临时表；应用层拼好再传入更可控 - 批量计算哈希值（如
MD5()）务必前置到写入阶段，运行时计算会吃光 CPU，尤其在GROUP BY场景下
函数体内嵌套 SQL 是性能断崖点
存储函数里写 SELECT ... FROM other_table WHERE x = NEW.y，本质是每次调用都触发一次独立子查询。游标循环中调用一次，等于 N 行 × M 次网络往返 + N×M 次优化器决策 + 锁竞争放大。这比直接 JOIN 慢一个数量级以上。
实操建议：
- 函数内禁止任何
SELECT、UPDATE、INSERT—— 所有数据依赖必须由调用方一次性提供 - 若逻辑真需关联查表，改用存储过程 + 显式事务，并把关联数据提前载入临时表（
CREATE TEMPORARY TABLE tmp AS (...)），再在过程内 JOIN - 用
SHOW CREATE FUNCTION func_name快速扫描函数体，确认是否含SELECT关键字；如有，基本可直接重构
