MySQL PREPARE 缓存解析树和未绑定的优化上下文，而非完整执行计划；EXECUTE 时复用模板计划但不重优化，参数值敏感场景易性能下降。
PREPARE 阶段缓存的不是“执行计划”，而是解析树和优化上下文
MySQL 的 PREPARE 确实会做一次语法解析、语义检查和初步优化，但它缓存的不是 SQL Server 那种带参数绑定值的完整执行计划（plan handle），而是一个中间结构：解析树（parse tree）+ 未完全绑定的优化上下文。这意味着当 EXECUTE 填入具体参数值时，优化器仍需基于当前统计信息、索引状态和参数实际类型重新评估——但不会重新解析 SQL 文本。
常见错误现象：ERROR 1295 (HY000): This command is not supported in the prepared statement protocol yet，说明你试图预处理不被协议支持的语句（如 SET @var = ... 或含分号的多语句），这和执行计划复用无关，是协议层限制。
EXECUTE 复用的是“模板级计划”，不是“值敏感计划”
比如 SELECT * FROM orders WHERE user_id = ? 在 PREPARE 阶段无法知道 ? 是 1 还是 1000000，优化器可能默认走全表扫描或选错索引；EXECUTE 时填入 @uid 后，MySQL 不会重新优化，而是硬跑那个模板计划。这就是为什么参数值差异大时，预处理反而更慢。
- 变量类型必须匹配：用
SET @uid = '123'（字符串）传给WHERE id = ?（INT 列），会触发隐式转换，导致索引失效 -
EXECUTE stmt USING @uid是合法的；EXECUTE stmt USING 123是非法的——必须通过用户变量传参 - 执行计划复用只在单个连接内有效，换连接就得重 PREPARE
存储过程里混用 PREPARE 和硬编码 SQL，执行计划行为不一致
存储过程内写死的语句（如 SELECT * FROM user WHERE id = 123）每次调用都走完整优化流程；而用 PREPARE stmt FROM @sql 动态拼接后执行，则受上述模板计划约束。二者混合使用时，容易误以为“都是预编译，应该一样快”，结果发现动态部分响应波动极大。
关键区别：
- 硬编码 SQL：每次调用都实时优化，执行计划随数据分布变化
-
PREPARE/EXECUTE：优化发生在 PREPARE 时刻（无参数值），EXECUTE 只填充并执行，不重优化 - 存储过程本身的“预编译”仅指语法校验和过程体解析，不影响其内部 SQL 的执行计划生成逻辑
真正影响执行计划新鲜度的是元数据变更，不是缓存机制
MySQL 会自动使缓存的解析结构失效，只要发生 DDL 操作（如 ALTER TABLE、DROP INDEX、ANALYZE TABLE）。但像 INSERT、UPDATE 这类 DML 不会触发失效——所以即使统计信息过期，PREPARE 缓存的结构也不会自动刷新，导致执行计划陈旧。
这不是 bug，是设计取舍：避免频繁 DML 导致缓存反复重建。但这也意味着，如果你依赖 PREPARE 加速高频查询，又长期不更新统计信息或改表结构，就可能持续跑着低效计划。
容易被忽略的一点：存储过程本身也受 stored_program_cache 缓存，但它的缓存对象是整个过程体的解析结果，和内部 SQL 的执行计划无关。别指望改了表结构后，不 DROP/CREATE PROCEDURE 就能让过程里的 PREPARE 自动适配新索引。
