mysql存储过程不缓存执行计划，其“预编译”仅限语法校验与解析，每次执行均实时生成执行计划；所谓“陈旧计划”实为统计信息过期、数据量变化或隐式转换等导致优化器误选路径。
MySQL 存储过程不缓存执行计划
MySQL 本身没有“存储过程编译后缓存执行计划”这一机制。你遇到的陈旧执行计划问题，大概率不是来自 MySQL 的存储过程，而是误将 SQL Server 或 Oracle 的行为套用到了 MySQL 上。MySQL 的存储过程确实是预编译的，但它的“预编译”仅指语法校验和语句解析阶段完成，并不生成、缓存或复用类似 SQL Server 中 plan_handle 那样的可重用执行计划。
真正被缓存的是查询缓存（MySQL 8.0 前）或 Prepared Statement 的解析树
MySQL 在 8.0 版本前曾有查询缓存（query_cache_type），但它缓存的是“完全相同的 SQL 文本 + 结果”，不是执行计划；该功能已在 8.0 中被彻底移除。当前版本中，如果使用 PREPARE/EXECUTE 方式调用参数化 SQL（包括在存储过程中动态拼接后执行），MySQL 会缓存解析树（parse tree）和部分优化上下文，但每次执行仍会重新走优化器流程——也就是说，EXPLAIN 看到的执行计划，是每次运行时基于当前统计信息、索引状态、参数值实时生成的。
- 存储过程内写死的 SQL（如
SELECT * FROM user WHERE id = 123）：每次调用都走完整优化流程 - 存储过程中用
CONCAT拼接的动态 SQL：每次拼完都是新语句，无任何缓存复用 - 存储过程中用
PREPARE stmt FROM @sql执行：MySQL 缓存的是该语句的解析结构，但优化仍发生在EXECUTE时刻
那为什么感觉“执行计划变慢了”？真实原因通常是这些
所谓“陈旧”，其实是底层数据或环境变了，而你的观察没同步更新。常见诱因包括：
-
ANALYZE TABLE没跑过，或者统计信息过期（information_schema.statistics中的cardinality值不准），导致优化器选错索引 - 表数据量突增（比如从 1 万行涨到 100 万行），但没触发自动重采样，优化器仍按小表策略选全表扫描
- 索引被误删或失效（
ALTER TABLE ... DROP INDEX或OPTIMIZE TABLE后未重建统计信息） - 存储过程里用了
SQL_NO_CACHE或客户端禁用了查询缓存逻辑，掩盖了原本可能的缓存加速效果（仅限 5.7 及更早）
验证和干预手段要盯准优化器输入，而不是“清计划缓存”
MySQL 没有 DBCC FREEPROCCACHE 这种命令，强行“清理执行计划”既不可行也无意义。你需要做的是让优化器拿到准确的输入：
- 手动更新统计信息：
ANALYZE TABLE your_table; - 检查实际执行计划：
EXPLAIN FORMAT=TRADITIONAL SELECT ...（注意在存储过程内无法直接 EXPLAIN，需把 SQL 提取出来单独测） - 确认参数值影响：同一存储过程，传入
id = 1和id = 999999可能触发完全不同路径，这不是缓存问题，是优化器对不同谓词的选择结果 - 避免隐式转换：比如
WHERE phone = 13800138000（phone 是 VARCHAR），会导致索引失效——这种“慢”会被误认为“计划陈旧”，实则是每次都在走错误路径
真正的复杂点在于：MySQL 不暴露执行计划缓存哈希键细节，也没法像 SQL Server 那样定位某条语句的 plan_handle。所以别找“清缓存”捷径，老老实实查 EXPLAIN、看统计信息、比对参数行为——这才是可控的调试路径。
