MySQL升级后，原本执行毫秒级完成的存储过程突然变成几秒甚至几十秒，这种情况并不少见。升级本身通常会带来优化器改进，但也可能让某些存储过程中的SQL语句走上完全不同的执行路径，比如索引选择错误、连接顺序变化、统计信息过期等，最终导致性能断崖式下跌。需要先明确一个核心概念：MySQL存储过程在调用时并不会被整体预编译为一个固定执行计划，而是每次调用都会对内部SQL语句重新解析和优化，所以性能下降的根源往往不在存储过程本身，而在其包含的SQL语句所使用的执行计划。
升级后存储过程突然变慢的根本原因
要理解重新编译存储过程为什么能解决性能问题，先要弄清MySQL在升级前后对存储过程的处理方式。存储过程在创建时，系统只会对其语法和权限进行校验，然后将其源码保存在数据字典中。在调用存储过程时，MySQL才真正解析过程体内部每条SQL语句，并交给优化器生成执行计划。对于存储过程中的静态SQL，优化器会利用当前表的统计信息和系统变量来确定最佳执行计划。一旦MySQL版本升级，优化器算法、默认配置、成本模型甚至索引统计信息都会发生变化，以前认为最优的执行计划可能不再被选中。
例如，某个查询原本使用索引A回表成本更低，升级后优化器因为统计信息偏离而选择了索引B，而索引B的选择性极低，导致扫描大量全表数据。另外，MySQL在升级过程中会重建数据字典，但表统计信息并不会自动全部更新，特别是那些长期没有执行ANALYZE TABLE的表，其统计信息仍停留在旧版本状态，优化器基于陈旧统计信息做出的判断自然不可靠。这时，存储过程内部的SQL虽然一个字都没改，但执行计划已经面目全非。
所谓“重新编译存储过程”，严格意义上是让MySQL重新评估存储过程中所有SQL语句的执行计划。MySQL不像SQL Server有存储过程级别的RECOMPILE指令，但可以通过ALTER PROCEDURE强制刷新存储过程的元数据，使存储过程在下次调用时重新解析。同时，重新执行ANALYZE TABLE来更新表和索引的统计信息，是让优化器重建正确执行计划的关键步骤。
如何重新编译存储过程并刷新执行计划
在MySQL中，最简单的重新编译操作是使用ALTER PROCEDURE命令，即使不修改任何代码，这个命令也会更新存储过程的修改时间，并触发MySQL对存储过程对象的重新加载。对于没有权限修改存储过程定义的场景，可以先DROP再CREATE，但这种方法需要完整的定义语句，操作风险较高。更推荐的方式是直接对存储过程内部涉及的表执行ANALYZE TABLE，让统计信息重新收集，从而使优化器生成新的执行计划。
下面演示一个实际案例。假设有一个存储过程proc_get_user_order，升级后性能明显下降，首先查看它内部的查询语句和执行计划。
-- 查看存储过程定义 SHOW CREATE PROCEDURE proc_get_user_order; -- 假设存储过程内部核心SQL如下 SELECT o.id, o.order_no, u.nickname, o.amount FROM orders o INNER JOIN users u ON o.user_id = u.id WHERE o.status = 1 AND o.create_time > '2024-01-01' ORDER BY o.create_time DESC LIMIT 100;
单独执行这条SQL，使用EXPLAIN观察执行计划。如果发现优化器选择的索引不是最优的，比如没有使用create_time索引而走了全表扫描，或者访问类型为ALL，那么基本可以确认是执行计划问题。此时先更新相关表的统计信息。
-- 重新收集表统计信息 ANALYZE TABLE orders; ANALYZE TABLE users; -- 再次查看执行计划 EXPLAIN SELECT o.id, o.order_no, u.nickname, o.amount FROM orders o INNER JOIN users u ON o.user_id = u.id WHERE o.status = 1 AND o.create_time > '2024-01-01' ORDER BY o.create_time DESC LIMIT 100;
如果ANALYZE TABLE之后执行计划仍然不理想，还可以强制刷新存储过程元数据。在MySQL 8.0中执行ALTER PROCEDURE时，可以保留原定义，只修改注释部分，这样既不会改变业务逻辑，又能让MySQL重新加载存储过程。
-- 通过修改注释触发存储过程重新加载 ALTER PROCEDURE proc_get_user_order COMMENT 'RELOADED ON 2025-01-01 FOR PERFORMANCE FIX';
需要注意，这个操作本身只是让存储过程元数据发生变更，MySQL会在下一次调用时重新解析过程体。要想让执行计划彻底改变，统计信息刷新才是核心。实践中最有效的组合是：先更新所有大表的统计信息，再执行ALTER PROCEDURE触发重新加载，然后对存储过程进行一次冷启动调用，观察执行时间。
用优化器提示强制修正存储过程中的慢SQL
如果重新编译后执行计划依然不理想，说明优化器的选择与预期存在偏差，此时可以在存储过程内的SQL语句中直接加入优化器提示，强制指定索引或连接顺序。MySQL中的FORCE INDEX、USE INDEX、IGNORE INDEX以及straight_join等提示都可以用来干预优化器行为。以刚才的查询为例，假设确定use create_time索引和普通索引的组合更优，可以在SQL中加上FORCE INDEX。
-- 在存储过程中使用FORCE INDEX优化
DELIMITER $$
CREATE PROCEDURE proc_get_user_order_fixed()
BEGIN
SELECT o.id, o.order_no, u.nickname, o.amount
FROM orders o FORCE INDEX (idx_create_time)
INNER JOIN users u FORCE INDEX (PRIMARY)
ON o.user_id = u.id
WHERE o.status = 1
AND o.create_time > '2024-01-01'
ORDER BY o.create_time DESC
LIMIT 100;
END$$
DELIMITER ;
使用FORCE INDEX的好处是执行计划完全由人工控制，即使统计信息更新不充分，也不会影响最终索引选择。但缺点是需要对SQL语句做改造，一旦表结构或数据分布发生较大变化，强制索引可能不再是正确选择。因此，FORCE INDEX更适合作为短期应急方案，长期来看还是要依靠合理的索引设计和定期的统计信息维护。
除了FORCE INDEX，还可以使用MySQL 8.0提供的优化器提示语法。比如用SET_VAR临时调整优化器开关或缓冲区大小，适用于某些复杂查询在优化器切换后成本计算异常的场景。例如，将join_buffer_size临时调大，或关闭半连接转换等。
-- 使用优化器提示设置变量
SELECT /*+ SET_VAR(join_buffer_size = 8M) */
o.id, o.order_no, u.nickname, o.amount
FROM orders o
INNER JOIN users u ON o.user_id = u.id
WHERE o.status = 1
AND o.create_time > '2024-01-01'
ORDER BY o.create_time DESC
LIMIT 100;
这类提示可以在存储过程的SQL里直接使用，不影响其他会话。需要特别注意的是，优化器提示必须紧跟SELECT、UPDATE、DELETE等关键字之后，且注释格式需要严格符合MySQL语法，否则可能被忽略。
从源头避免升级后存储过程性能问题的长期方案
重新编译存储过程只是一次性修复手段，真正健康的MySQL环境还需要建立一套预防机制。升级前应该在生产环境备份做过一次完整的性能基线测试，重点收集所有存储过程的平均执行时间和慢查询日志。通过对比升级前后的慢查询日志，可以迅速锁定有哪些存储过程出现性能恶化，再针对其中的SQL语句做执行计划分析。
升级后的日常运维中，定期执行ANALYZE TABLE是保持统计信息准确的必要操作。尤其对于数据频繁增删改的大表，建议在业务低峰期定时收集统计信息。同时可以开启MySQL的performance_schema，并利用sys schema中的statements_with_runtimes_in_95th_percentile等视图，找出执行时间排名靠前的存储过程语句。
-- 查看执行时间超过平均水平的SQL语句 SELECT SCHEMA_NAME, DIGEST_TEXT, AVG_TIMER_WAIT, MAX_TIMER_WAIT FROM performance_schema.events_statements_summary_by_digest WHERE SCHEMA_NAME = 'your_db' ORDER BY AVG_TIMER_WAIT DESC LIMIT 20;
在存储过程的开发习惯上，应将业务逻辑中的高频查询尽量拆分为简单SQL，避免在一个存储过程中堆积大量复杂关联，这样不仅便于优化器生成稳定计划，也方便后续单独调优。如果某个存储过程始终因为优化器版本变化而产生不稳定的执行计划，可以考虑用存储过程内的动态SQL搭配FORCE INDEX，或者使用专门的查询重写插件来统一调整执行路径。
最后需要强调的是，MySQL升级并不总意味着性能提升。如果存储过程性能下降是由优化器回归引起的，并且调整SQL也无法解决，可以暂时保留旧版本MySQL，或者查询官方bug库看是否有已知问题。但绝大多数情况下，通过更新统计信息、重建存储过程、添加合理的优化器提示，都能恢复甚至超越原来的执行效率。将重新编译存储过程纳入升级预案，并把上述排查步骤固化到运维手册中，就能避免升级后被动救火。