预编译语句缓存失效的典型表现是高并发下参数化查询变慢，根本原因是绑定参数类型不一致触发隐式转换，导致执行计划无法复用；必须关闭pdo模拟预处理、统一字符集、显式指定参数类型，并合理设计索引与管理statement生命周期。
预编译语句缓存失效的典型表现
高并发下参数化查询变慢，不是因为用了 PDO::prepare，而是执行计划没复用——pg_stat_statements 里同一 SQL 文本的 calls 很低、total_time 却很高；EXPLAIN ANALYZE 显示反复生成新计划，甚至出现 Seq Scan 而非 Index Scan。根本原因常是绑定参数类型不一致，触发隐式转换，导致数据库认为“这是另一条语句”。
PDO 中强制复用预编译语句的关键配置
默认 PDO 在 MySQL 下会启用模拟预处理（PDO::ATTR_EMULATE_PREPARES = true），这等于没预编译——语句在 PHP 层拼接，完全绕过服务端缓存。必须显式关闭：
-
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false)，否则prepare调用不发往 MySQL，缓存无从谈起 - 连接 DSN 中加上
;charset=utf8mb4，避免因字符集不一致导致参数类型推断失败（如把'123'当字符串而非整数） - 对数字类参数，显式用
bindValue($param, $value, PDO::PARAM_INT)，不依赖execute([$value])的自动推断——PHP 7.4+ 对null或'0'推断不稳定
让索引在参数化后依然生效的实操点
参数化本身不破坏索引，但写法不当会让优化器“看不见”索引。常见踩坑点：
- 查询中对字段加函数：写成
WHERE UPPER(name) = ?→ 改为WHERE name = LOWER(?)，并在name字段建函数索引CREATE INDEX idx_name_lower ON users ((LOWER(name))) - 复合索引顺序错配：索引是
(tenant_id, created_at)，但查询只传created_at = ?→ 必须补上tenant_id = ?，或重建索引为(created_at, tenant_id)（仅当created_at高选择性时） - 枚举值用单参数
IN (?)→ 改为IN (?, ?, ?)，否则优化器无法估算基数，倾向全表扫
高并发下 statement 生命周期管理
缓存失效常被误判为 SQL 问题，实际是资源泄漏：MySQL server has gone away 或 Commands out of sync 多半源于 PDOStatement 实例未释放。
- 每次
prepare后，用完立刻unset($stmt)，别等 GC；循环内重复 prepare 同一语句却不 unset，MySQL 侧句柄累积，达到max_prepared_stmt_count就拒绝新 prepare - 确认
wait_timeout与应用层连接空闲超时匹配，否则连接被服务端断开，应用还拿旧连接调prepare，必然失败 - 在 Swoole 等协程环境，禁止跨协程共享
PDO或PDOStatement实例——它们非协程安全，必须 per-request 新建或从连接池取隔离实例
