create procedure本身不自动提升性能，仅在满足静态sql、高频调用、网络延迟高、多语句事务等全部条件时才可能提速；其“预编译”实为首次解析与执行计划缓存，非永久字节码，且mysql 8.0已移除查询缓存，仅缓存执行计划。
CREATE PROCEDURE 本身不带来自动性能提升，所谓“预编译提速”只在特定条件下成立——它省掉的是首次调用时的语法解析和语义检查开销，后续调用复用的是执行计划缓存（plan cache），而非“编译结果”。MySQL 8.0 的执行计划缓存是语句级的，不是过程级的。
预编译 ≠ 每次都跳过优化器
很多人误以为存储过程像 C 函数一样“编译一次、永久运行”。实际上：
- MySQL 不会为整个
PROCEDURE生成机器码或中间字节码；所谓“预编译”仅指首次CALL时完成 SQL 解析、权限校验、对象存在性检查，并为其中每条语句生成执行计划（plan） - 后续调用仍会触发查询优化器，但若语句结构不变、表统计信息未更新、变量值不影响索引选择性，则可能复用已缓存的执行计划
- 一旦语句中含变量（如
WHERE id = @v），优化器无法准确估算选择性，常弃用索引——此时“预编译”毫无意义，每次执行都可能走全表扫描
什么情况下真能提速？
只有满足以下全部条件时，你才可能观察到明显提速：
- 存储过程内全是静态 SQL（无变量、无动态拼接），例如
SELECT * FROM users WHERE status = 'active' - 过程被高频调用（每秒数次以上），且网络往返延迟显著（比如应用与 DB 跨公网）
- 过程封装了多条语句+事务边界（如
BEGIN; INSERT; UPDATE; COMMIT;），避免客户端多次 round-trip - 对比基准是“客户端逐条发送 SQL”，而不是“用
PDO::prepare()+ 绑定参数执行相同逻辑”
为什么常测不出提速？
现代应用层普遍使用连接池和预编译接口，已吸收大部分“解析/传输”开销。此时存储过程反而引入新瓶颈：
-
EXPLAIN无法直接分析CALL proc_name()，必须拆出内部语句单独测试——而多数人跳过这步，误把慢 SQL 归咎于“存储过程太重” - 过程内使用
DECLARE CURSOR或WHILE循环处理数据，实际是单行迭代，比客户端批量拉取再处理更慢 - MySQL 8.0 移除了查询缓存（Query Cache），但很多人仍默认“存储过程能缓存结果”，其实它不缓存数据，只缓存计划
- 过程体中若含临时表、JSON 解析、子查询嵌套，这些操作本身开销远大于“少一次 parse”，反而拖累整体
真正影响快慢的从来不是“有没有预编译”，而是那条最慢的 SELECT 是否命中索引、是否触发磁盘排序、是否被锁住——这些细节藏在过程内部，不挖出来看 EXPLAIN FORMAT=TREE 就永远找不到根因。
