存储过程真能提升 MySQL 查询性能吗？
多数情况下不能，甚至可能更慢。MySQL 存储过程本身不自带“性能加成”，它只是把 SQL 逻辑封装在服务端执行，省去网络往返和客户端解析开销——但这个收益只在特定场景明显：高频调用、多语句组合、参数化逻辑复用，且数据量不大时。如果单条查询本身已很重（比如全表扫描 + 复杂 JOIN），套个
CREATE PROCEDURE不会变快；反而因存储过程缺乏查询缓存（MySQL 8.0+ 已移除 QCache）、无法被优化器深度内联，有时还更难调试。
哪些操作放进存储过程才值得？
适合用存储过程的不是“任意 SQL”，而是满足以下全部或多数条件的操作：
需要多次执行的事务性操作，比如“扣库存 + 写订单 + 记日志”三步必须原子完成，且由不同应用模块调用 业务逻辑强依赖数据库内部状态，例如根据user_level动态拼接 WHERE 条件，且该字段常更新、不适合放应用层缓存 批量处理小数据集（LOOP +
SELECT ... INTO比应用层逐条取再判断更省连接开销 规避 ORM 生成低效 SQL 的场景，比如 Laravel 的 Eloquent 在关联嵌套深时容易 N+1，而用存储过程预聚合好结果再返回单行，效果立竿见影
写存储过程时最容易拖慢性能的 3 个坑
很多性能问题不是出在逻辑本身，而是写法细节：
在循环里反复查同张表：比如用WHILE遍历 ID 列表，每次循环都
SELECT ... FROM orders WHERE id = @id—— 应该先用临时表或
JOIN一次性查完 忽略游标（
CURSOR）的隐式锁和内存消耗：游标本质是服务端结果集缓存，大数据量下易触发
sort_buffer_size溢出，改用基于集合的写法（如
INSERT ... SELECT）通常更快 硬编码 LIMIT 而非用变量：写成
SELECT * FROM logs LIMIT 100没问题，但写成
SELECT * FROM logs LIMIT @n会导致执行计划无法复用，MySQL 8.0.22+ 才支持 PREPARE 中的变量 LIMIT，旧版本得用动态 SQL +
CONCAT拼接，但又失去语法检查
替代方案比硬上存储过程更有效
遇到性能瓶颈，先确认是不是存储过程的问题本身：
用EXPLAIN FORMAT=TREE看慢查询是否卡在索引缺失或类型转换，而不是“没走存储过程” 把存储过程里的核心 SQL 单独拿出来执行，对比
SHOW PROFILE各阶段耗时，常发现 90% 时间花在
Sending data（即磁盘读/网络发包），这时加索引或减少字段比改存储过程有用得多 对高频只读场景，考虑用物化视图思路：建一张汇总表，用
EVENT定时刷新，应用直接查这张表 —— 比每次调用存储过程实时计算快一个数量级
真正复杂的逻辑编排，MySQL 存储过程语法贫弱、调试困难、版本管理麻烦，不如把关键路径收口到应用层用 Go/Python 做，只留原子 SQL 给数据库。
