预编译语句在高频写入场景下更快，核心是跳过重复的解析与优化步骤；其生效前提为同一连接内相同模板执行≥3次，且仅参数值可占位，表名列名等结构不可动态化。
预编译语句在高频写入场景下更快，核心不是“它天生快”，而是跳过了每次执行都必须做的重复解析和优化步骤——这部分开销在单次查询里不明显，但在每秒数百次 INSERT 或 UPDATE 时会迅速成为瓶颈。
MySQL 每次普通 SQL 执行都要重走完整解析链路
你写一句 INSERT INTO users (name, age) VALUES ('Alice', 25)，MySQL 不是直接执行。它得先做：
- 词法分析：拆出
INSERT、INTO、表名、字段、值等 token - 语法分析：确认括号匹配、逗号位置、是否符合 INSERT 语法规则
- 语义分析：检查
users表是否存在、name和age字段类型是否匹配 - 查询优化：生成逻辑计划（比如要不要用索引）、估算行数、选择访问路径
- 生成物理执行计划：确定最终怎么扫描、怎么写入、是否需要临时表
这些步骤加起来，在高并发下会争抢 QUERY_COMPILE latch，导致线程排队等待。而预编译只在第一次 PREPARE 时走完全部流程，后续 EXECUTE 直接复用已缓存的执行计划。
预编译真正生效的前提是复用同一模板 ≥ 3 次
别以为只要写了 ? 就自动变快——MySQL（和大多数数据库）对“复用阈值”有实际判断：
- 同一连接内，相同结构的 SQL 被
PREPARE后，再调用EXECUTE≥ 3 次，优化器才倾向启用计划缓存 - 如果每次执行前都
DEALLOCATE PREPARE再重PREPARE，等于白干 - PHP 中用
mysqli_prepare()创建的mysqli_stmt对象必须复用，不能每次 new 一个新实例 - Java JDBC 中也一样：
PreparedStatement实例要缓存并复用，而不是每次conn.prepareStatement(...)都新建
漏掉这点，性能可能比普通 mysqli_query() 还差——因为多了对象创建、绑定、参数拷贝的额外开销。
动态部分不能塞进 ? 占位符，否则报 ER_PARSE_ERROR
常见翻车点：试图用 ? 替换表名、列名、ORDER BY 字段或 LIMIT 的偏移量。例如：
PREPARE stmt FROM 'SELECT * FROM ? ORDER BY ?';
这会直接报错 ER_PARSE_ERROR，因为 MySQL 无法在预编译阶段确定对象结构。能参数化的只有「值」（WHERE name = ?、VALUES (?, ?)），不是「结构」。
如果你的写入逻辑需要动态表名（如分表场景），只能拼接 SQL 字符串，但必须严格校验输入（比如白名单匹配 log_202606 这类固定格式），不能直接插用户输入。
断连后预编译失效，长期服务必须处理重连逻辑
预编译语句作用域是 session 级，MySQL 连接断开（超时、网络抖动、服务重启）后，所有 PREPARE 的语句都会丢失。此时若继续调用 EXECUTE，会报 Unknown prepared statement handler 错误。
真实服务中必须做到：
- 连接池（如 HikariCP、mysqli::real_connect）开启
autoReconnect并不可靠，不能依赖它恢复预编译状态 - 每次从连接池取连接后，先检查是否已有可用的
PreparedStatement实例；没有就重新prepare - PHP 中可封装一个懒加载的
getPreparedStmt($sql)方法，内部用连接 ID + SQL hash 做缓存键
这个细节在压测初期常被忽略，直到某次连接重建后批量写入突然全量降速，才意识到预编译根本没生效。
