MySQL存储函数中游标慢的主因是单行遍历开销大且易引发N×M级查询放大，叠加子查询导致执行计划失控；应优先用JOIN、临时表或客户端处理替代。
为什么 MySQL 存储函数里用游标就容易变慢
游标在 MySQL 中本质是单行遍历，每次 FETCH 都触发一次内部结果集定位和状态维护，开销远高于集合操作。尤其当游标循环体内还嵌套 SELECT 或 UPDATE 时，会形成“N × M”级查询放大——比如游标扫 1000 行，每行查一次关联表，实际执行 1000 次独立查询。
更隐蔽的问题是：游标默认使用 READ ONLY 和 NO SCROLL，但只要函数里出现临时表、子查询或排序，MySQL 可能被迫将游标结果缓存在内存/磁盘，进一步拖慢初始化速度。
- 避免在游标循环中执行任何 SQL 语句——把所有需要的数据，提前用
JOIN或LEFT JOIN一次性查出来，存入临时表或派生表 - 如果必须逐行处理，优先改用客户端逻辑（如 Python/Java）做聚合或判断，让数据库只负责高效读写
- 确认游标是否真不可替代：多数场景下，
GROUP BY + HAVING、窗口函数（MySQL 8.0+）、或INSERT ... SELECT都能替代游标逻辑
存储函数里写复杂子查询为什么拖慢执行
MySQL 存储函数不允许直接使用动态 SQL（PREPARE），所以开发者常靠多层嵌套子查询“硬凑”逻辑。但这类查询极易触发全表扫描、丢失索引、或让优化器误判执行计划——尤其当子查询含 ORDER BY、LIMIT 或相关子查询（correlated subquery）时。
典型表现是：单独执行子查询很快，但塞进函数后整体耗时激增；EXPLAIN 显示 type=ALL 或 rows 值异常高；函数被调用多次时，无法复用执行计划（函数内联限制）。
- 把高频复用的子查询逻辑拆成视图（
CREATE VIEW），函数中直接SELECT * FROM view_name，便于优化器预估和索引下推 - 用临时表承接中间结果：
CREATE TEMPORARY TABLE tmp_result AS (SELECT ...)，再对tmp_result做后续过滤或连接，比反复跑子查询稳定 - 检查 WHERE 条件是否导致索引失效：比如对字段用函数（
WHERE YEAR(create_time) = 2024）、隐式类型转换（WHERE user_id = '123'）、或LIKE '%abc'
哪些情况不该用存储函数，而该换方案
MySQL 存储函数设计初衷是“简单计算或封装原子逻辑”，不是业务编排引擎。一旦函数里出现事务控制（START TRANSACTION）、错误重试、跨库访问、或依赖会话变量（@var），性能和可维护性都会快速恶化。
常见误用包括：用函数实现分页统计、生成订单号、校验用户权限链、或调用 SLEEP() 做延时重试——这些操作在应用层更可控，也更容易加缓存、降级或监控。
- 涉及 I/O 或网络调用（如调用外部 API）：必须移出数据库，函数不支持异步或超时控制
- 需要高并发写入或低延迟响应：函数执行期间会持有行锁/表锁，且无法并行化，易成瓶颈
- 逻辑随业务频繁变更：修改存储函数需 DBA 权限，上线流程重，不如应用代码灰度发布灵活
如何验证优化是否生效
别只看单次执行时间，重点观察函数在真实负载下的行为：是否减少磁盘 I/O、是否降低 Handler_read_* 计数、是否避免了 Creating sort index 等临时操作。
用 SHOW PROFILE FOR QUERY N 查看各阶段耗时（注意开启 SET profiling = 1）；用 performance_schema 中的 events_statements_history_long 找出慢函数调用上下文；对关键函数加 SELECT BENCHMARK(1000, your_function()) 做粗略压力测试。
- 对比优化前后
SHOW STATUS LIKE 'Handler%'中Handler_read_next和Handler_read_rnd_next的增长量，下降明显说明减少了随机扫描 - 若函数被用于
SELECT列表（如SELECT id, calc_score(user_id) FROM users），务必确认该列没被索引覆盖——否则优化器可能放弃使用索引 - MySQL 5.7 对存储函数内联支持极弱，即使逻辑简单，也可能拒绝使用索引；升级到 8.0 并启用
optimizer_switch='derived_merge=on'能缓解部分问题
真正卡住性能的，往往不是某一行代码，而是游标与子查询叠加带来的执行计划失控。越想在函数里“把事情做完”，数据库越难优化——留出边界，让每层只做它最擅长的事。
