MySQL函数调用有明显开销，标量函数单次约10–50ns，百万行即增10–50ms；UDF开销为内置函数3–10倍；LIKE前导通配符、FIND_IN_SET()、JSON函数及日期格式化函数易致性能问题；应通过performance_schema、EXPLAIN FORMAT=JSON等定位瓶颈，并优先用应用层处理或改写为索引友好形式替代。
MySQL 函数调用本身有明显开销
直接在 SELECT 或 WHERE 中调用自定义函数（CREATE FUNCTION）或内置函数（如 DATE_FORMAT()、CONCAT()），都会触发额外的函数栈帧创建、参数拷贝、类型转换和返回值处理。尤其当函数被用于大结果集的每一行时，开销会线性放大。
- 标量函数（如
UPPER()）单次调用开销约 10–50ns，看似微小，但百万行即增加 ~10–50ms（不含 I/O） - 用户定义函数（UDF 或 SQL-defined function）开销通常是内置函数的 3–10 倍，因涉及 SQL 解析上下文切换
- 若函数内含子查询（比如
(SELECT COUNT(*) FROM t2 WHERE t2.id = t1.ref)），则退化为“每行一次嵌套查询”，极易拖垮性能
哪些 MySQL 函数特别容易引发性能问题
不是所有函数都平等。以下几类在实际慢查中高频出现，且优化空间有限：
-
LIKE带前导通配符：name LIKE '%abc'—— 无法走索引，且每次需全字符串扫描匹配 -
FIND_IN_SET()—— 内部按逗号分隔遍历，无索引支持，数据量 >1k 行时显著变慢 -
JSON_EXTRACT()+JSON_CONTAINS()在未建虚拟列+索引时，每次解析整个 JSON 字段（即使只取一个字段） -
STR_TO_DATE()和DATE_FORMAT()在WHERE子句中使用（如DATE_FORMAT(create_time, '%Y-%m') = '2024-01'）—— 导致索引失效
如何判断函数是否成为瓶颈
不能靠猜。要用 MySQL 自带工具定位真实耗时点：
- 开启
performance_schema并查events_statements_summary_by_digest，看SUM_TIMER_WAIT和COUNT_STAR是否异常高 - 对慢查询执行
EXPLAIN FORMAT=JSON，重点看query_cost和used_columns是否包含函数计算列 - 用
SHOW PROFILE FOR QUERY N（需先SET profiling = 1），观察Function阶段耗时占比 - 对比改写前后：把函数逻辑提到应用层（如 Python/Java 中格式化日期），再测 QPS 和平均响应时间
替代方案比“优化函数”更有效
多数情况下，函数不是该优化，而是该绕开：
- 日期范围查询不用
DATE_FORMAT()，改用create_time >= '2024-01-01' AND create_time - 枚举类字符串匹配不用
FIND_IN_SET()，改用status IN ('active', 'pending')或正则status REGEXP '^(active|pending)$'（后者仍慎用） - JSON 字段查询频繁时，加虚拟列：
ALTER TABLE orders ADD status_code TINYINT AS (JSON_EXTRACT(meta, '$.status')) STORED;
再在该列建索引 - 复杂逻辑（如多表关联+条件聚合）不要塞进函数，拆成临时表或 CTE 分步计算
IFNULL() 或 COALESCE() 可能是压垮执行计划的最后一根稻草。真正要盯的不是“能不能快一点”，而是“这一行计算，是不是非得在数据库里做”。 
