先确认存储函数是否真被高频调用：若慢日志中无含函数名的sql，则卡顿源于整条查询（如join中每行调用），而非函数本身；函数体内sql需单独explain分析，警惕隐式转换、循环放大及函数调用固有开销。
存储函数慢，先确认它真在被调用
很多“存储函数执行慢”的问题，本质是误判——函数压根没被调用，或者只在调试语句里跑了一次。MySQL 的 slow_query_log 默认不记录存储函数内部逻辑，只记录调用它的 SQL 语句（比如 SELECT my_func(123)）。所以第一步不是看函数体，而是确认：这条调用本身是否进了慢日志。
- 查慢日志时，搜索包含函数名的完整 SQL，例如
SELECT my_calc_total(456)，而不是只搜my_calc_total - 如果该 SQL 没出现在慢日志里，但应用端感知到卡顿，大概率是函数被高频循环调用（比如在
SELECT ... FROM t1 JOIN t2中对每行都调用一次），此时慢的是整条查询，不是函数单次执行 - 用
SHOW PROCESSLIST观察线程状态，若看到Executing状态持续数秒且Info列显示函数调用，才说明函数真正在耗时
函数体内不能用 EXPLAIN，得拆开看
对存储函数本身执行 EXPLAIN 是无效的——它不是查询语句，没有执行计划。真正要分析的是函数里实际执行的 SQL，比如 SELECT ... FROM orders WHERE user_id = in_user_id 这类语句。
- 把函数体里的核心 SQL 单独拿出来，用
EXPLAIN分析，重点看type是否为ALL、rows是否远超预期、key是否为空 - 注意参数传递带来的隐式转换：如果函数定义参数是
INT，但调用时传了字符串（如my_func('123')），MySQL 会自动转类型，导致索引失效；检查EXPLAIN的Extra列是否出现Using where; Using index或Using temporary; Using filesort - 函数内若含循环（
WHILE/REPEAT）或嵌套查询，务必估算最坏情况下的执行次数——1 行输入触发 100 次子查询，就等于放大 100 倍开销
函数调用开销本身不可忽略
MySQL 存储函数每次调用都有固定解析、上下文切换、权限校验成本，尤其在高并发场景下会被显著放大。这不是 bug，是设计使然。
- 对比直接写 SQL 和封装成函数：同一逻辑，函数调用通常比内联 SQL 慢 10%~30%，数据量越大、调用越频繁，差距越明显
- 避免在
WHERE或ORDER BY中调用函数，例如WHERE DATE(created_at) = '2026-08-11'—— 这会让整个列无法走索引；应改用范围查询：WHERE created_at >= '2026-08-11 00:00:00' AND created_at - 函数返回值若被用于 JOIN 条件（如
JOIN users u ON u.id = my_func(t.user_id)），优化器几乎无法做任何预判，极易退化为嵌套循环
临时方案：用 SELECT ... INTO 替代函数返回
当函数逻辑简单（比如查一个关联字段）、又必须复用时，比硬写函数更轻量的做法是：用变量暂存结果，再参与后续逻辑。
- 例如原函数
GET_USER_NAME(user_id)只是SELECT name FROM users WHERE id = p_id，可改为： SELECT name INTO @user_name FROM users WHERE id = 123;<br>SELECT ..., @user_name AS user_name FROM orders WHERE user_id = 123;
- 这样绕过函数调用栈，也避免重复解析；但注意变量作用域仅限当前 session，不能跨语句复用
- 若需跨查询复用，考虑用临时表或物化中间结果，而不是靠函数反复计算
