MySQL Prepared statement 为什么会自动重新预编译

MySQL 的 Prepared statement 会在当前会话中缓存一份内部结构，但这份结构依赖表和视图的元数据。参数值改变时，通常只需要重新执行；如果引用对象的列、定义或表定义缓存发生变化，旧结构就可能过期，服务器会在下一次执行前自动重新解析并建立结构。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/statement-caching.html

先分清：缓存的是内部结构，不是一次执行结果

服务端收到 Prepared statement 后，会把语句转换成可复用的内部结构，并按会话保存。再次执行时，绑定参数可以不同，但语句的解析结果、引用对象和列展开关系仍要与当前数据库定义一致。缓存按 session 隔离，一个连接里的预处理语句不会被另一个连接直接复用；连接结束时，该会话缓存也会被丢弃。

例如 SELECT * 并不是一个永远不变的列集合。解析时它会展开为当时表中的列，如果之后增加、删除或重命名列，继续使用旧内部结构就可能得到错误结果。MySQL 选择在下一次执行时自动 reprepare，代价是重新解析并重建内部结构。

哪些变化会触发自动 reprepare

排查时先看引用对象是否发生了元数据变化。常见触发源包括创建、删除、修改、重命名或清空表的 DDL，也包括对表执行 ANALYZE TABLE、OPTIMIZE TABLE、REPAIR TABLE。如果引用的表或视图被移出 table definition cache，隐式腾挪或显式执行 FLUSH TABLES，下一次执行也可能重新解析。

这里要和数据变化区分开：INSERT、UPDATE 改的是表内容，不改变表的元数据；普通 SELECT 也不会因为读了新数据就让 Prepared statement 自动重新预编译。存储过程、函数、触发器和事件同样有缓存逻辑，但本文只把它们作为边界，不把问题扩大成存储程序调优。

用 Com_stmt_reprepare 判断是不是频繁发生

MySQL 用全局状态变量 Com_stmt_reprepare 统计 Prepared statement 的重新预编译次数。单次增长并不能证明有性能事故，关键是把它与 DDL、维护任务和应用延迟放在同一时间轴上看。下面的命令只读取指标，不会改变配置。

-- 读取当前实例累计的自动重新预编译次数
SHOW GLOBAL STATUS LIKE 'Com_stmt_reprepare';

-- 对照预处理执行总量，观察发布窗口内的增长趋势
SHOW GLOBAL STATUS LIKE 'Com_stmt_execute';

如果发布前后 Com_stmt_reprepare 快速增长，同时执行延迟抬升，先核对是否有批量 ALTER、表维护或 FLUSH TABLES。手册说明服务器最多尝试三次 reparse，三次都失败才返回错误；因此“语句偶尔变慢”和“执行直接报错”可能是同一类元数据失配的不同表现。

生产环境的处理方案与边界

确认触发源后，不要先把 Prepared statement 全部关闭。更稳妥的处理顺序是：把结构变更纳入发布记录，避免应用高峰执行大批量 DDL；将 ANALYZE TABLE、OPTIMIZE TABLE 等维护任务放入可观察窗口；必要时把表定义缓存刷新从临时操作改为有回滚和监控的运维动作。

如果 SQL 使用了 SELECT *，可以在业务允许时改成明确列清单，降低列结构变化对语句内部结构的影响，但这不是消除 reprepare 的万能开关。真正要验证的是：DDL 或缓存刷新发生后，计数是否增长、请求延迟是否恢复、应用连接是否看到重复错误。参数绑定本身、连接池复用和执行计划问题，应分别建立指标，不要都归因给自动重新预编译。

相关问题

只有 INSERT 和 UPDATE 也会触发 reprepare 吗？

单纯改变行数据通常不改变元数据，不是主要触发原因；若同一窗口还有 DDL、表维护或缓存刷新，仍应优先查这些动作。

为什么重启连接后现象暂时消失？

预处理缓存按会话保存，连接结束会丢弃旧结构。重连只能清掉当前会话缓存，不能替代对 DDL 和表定义变化的定位。

Com_stmt_reprepare 增长就一定要调参数吗？

不一定。先对齐 DDL、维护任务、刷新命令与延迟，再决定调整发布流程或观察方式；不要仅凭累计值做结论。