PREPARE + EXECUTE 比直接 mysql_query() 快，因预编译提前完成解析、语法检查和执行计划生成，后续仅传参复用计划，显著降低高并发下CPU开销；但需确保服务端真实预编译生效、合理管理句柄生命周期，并避免在短连接或动态SQL等不适用场景滥用。
为什么反复执行相同SQL时，PREPARE + EXECUTE 比直接 mysql_query() 快
因为预编译把 SQL 的解析、语法检查、执行计划生成阶段提前做了，后续只传参、复用计划。尤其在高并发或参数变化频繁但结构不变的场景（比如用户登录校验、订单状态更新），省掉每次 parse 和 optimize 能明显降低 CPU 开销。
但注意：MySQL 服务端预编译语句是会话级的，断连就失效；客户端驱动（如 MySQLi、PDO）的预编译可能只是模拟——实际还是拼 SQL 发送，这点容易误判效果。
- 确认是否真走服务端预编译：查
SHOW STATUS LIKE 'Com_prepare_sql'，有递增才说明生效 - PDO 默认用
PDO::ATTR_EMULATE_PREPARES = true，等于没预编译；必须显式关掉：$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false) - MySQL 5.7+ 对简单查询（如单表主键查找）会自动缓存执行计划，预编译收益变小；复杂 JOIN 或带子查询的语句才更依赖预编译稳定性能
如何安全复用 PREPARE 语句避免“Unknown prepared statement handler”错误
错误通常发生在：语句被 DEALLOCATE PREPARE 了，或连接重用时未检查句柄是否存在，或连接池中连接被复用但预编译未重建。
关键不是“一次 prepare 多次 execute”，而是“按需 prepare + 显式生命周期管理”。
- 不要在函数里每次调用都
PREPARE，也不要在连接初始化时盲目全量 prepare 所有 SQL - 推荐做法：首次执行前检查
SELECT @sql_handle := ?是否为空，或捕获ER_UNKNOWN_STMT_HANDLER错误后重新PREPARE - 使用连接池时（如 ProxySQL、PHP-FPM 长连接），必须在连接复用前确保预编译句柄有效，或干脆在业务逻辑层做轻量缓存（例如用
md5($sql)当 key 存句柄名）
PDO/MySQLi 中开启真实预编译的配置差异和坑点
同一段代码，在不同驱动、不同 MySQL 版本下行为可能完全不同。最常踩的坑是以为开了 prepare() 就等于服务端预编译。
- MySQLi：默认走真实预编译，但需确认
mysqli_options($link, MYSQLI_OPT_PREPEND_DRIVER_NAME, false)未干扰（极少用，但某些旧封装会设） - PDO：必须同时满足两个条件——
PDO::ATTR_EMULATE_PREPARES = false且 MySQL 服务端版本 ≥ 5.1（5.0 不支持） - PHP 8.1+ 中，
PDO::ATTR_EMULATE_PREPARES默认为false，但很多项目仍显式设为true兼容老逻辑，要翻代码确认 - 如果 SQL 含变量（如动态表名、ORDER BY 字段），不能用预编译参数占位符，只能拼接；此时预编译无效，还可能因 SQL 注入风险被误信“已防注入”
预编译语句的内存与连接开销你可能没算过
每个预编译句柄在 MySQL 端占用约 1–2KB 内存，看似不多，但万级连接 × 百条预编译 = 几百 MB 仅用于句柄元数据。更隐蔽的问题是：长时间空闲的预编译语句不会自动释放，wait_timeout 只杀连接，不清理句柄。
- 定期清理：可在应用空闲时执行
DEALLOCATE PREPARE xxx，或用RESET QUERY CACHE（虽不相关但常被误试） - 监控指标：关注
Threads_cached和Prepared_stmt_count，后者持续上涨说明有泄漏 - 短连接场景（如 CLI 脚本）完全没必要预编译——连接建立成本远高于 parse 成本，反而增加额外 round-trip
预编译不是银弹。它真正起作用的地方，是长连接、高频同构查询、且服务端执行计划不稳定（比如受统计信息变化影响大）的组合场景。其他情况，先看慢日志里 Query_time 和 Parse_time 占比，再决定动不动 PREPARE。
