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()可能是压垮执行计划的最后一根稻草。真正要盯的不是“能不能快一点”，而是“这一行计算，是不是非得在数据库里做”。
