pdo::prepare在抢购中变慢的根本原因是pdo::attr_emulate_prepares未关闭，导致php层模拟预处理、执行计划无法复用，加之外部参数类型混乱、字符集缺失、whereraw滥用及statement泄漏等问题共同引发性能雪崩。
高并发抢购场景下，修复SQL注入本身不会拖慢性能；真正导致性能下降的，是修复过程中错误地退化为模拟预处理、参数类型混乱、或滥用ORM拼接——这些操作让数据库无法复用执行计划，反而把原本毫秒级的查询拉到百毫秒以上。
pdo::prepare 为什么在抢购里变慢了
现象是同一SQL语句 SELECT * FROM stock WHERE sku_id = ? AND version = ? 在高并发下响应时间飙升，pg_stat_statements 或 performance_schema 显示 calls 很低但 total_time 极高，EXPLAIN ANALYZE 反复生成新执行计划，甚至退化成全表扫描。
- 根本不是用了
PDO::prepare，而是PDO::ATTR_EMULATE_PREPARES没关——PHP 层自己拼 SQL，MySQL 根本没收到预编译请求，缓存无从谈起 - 用户传参是字符串
'123'，但库存校验逻辑里又用intval()转一次，再绑定时类型变成PDO::PARAM_INT，而另一处直接execute([$sku])让 PDO 推断为字符串，类型不一致 → 执行计划分裂 - 连接 DSN 缺少
;charset=utf8mb4，某些客户端发来带 emoji 的用户 ID（如"sku_?123"），服务端字符集 fallback 导致参数推断失败，触发隐式转换
whereRaw 和 Eloquent 的“安全幻觉”
很多团队以为上了 Laravel 就万事大吉，结果抢购接口里写着 User::whereRaw("sku = '{$_POST['sku']}'")->first()，或者在事务里用 DB::select(DB::raw("UPDATE stock SET qty = qty - 1 WHERE sku = '$_POST[sku]'")) ——这类写法完全绕过参数绑定，且在高并发下极易因锁竞争+全表扫描雪崩。
-
whereRaw必须配bindings参数：whereRaw('sku = ?', [$sku])，否则等于裸奔 - 模型作用域（scope）里拼接字符串、accessor 中调用原生查询、
boot()静态方法里写DB::statement()，都是静默高危点，上线后几乎没人 review - 批量扣减库存用
whereIn('sku', $skus)时，若$skus是动态数组，别图省事写成IN (?)，必须展开为IN (?, ?, ?)，否则优化器无法估算基数，倾向走全表扫
statement 生命周期失控引发的连锁故障
抢购峰值每秒几百次请求，每个请求都 $pdo->prepare($sql) 却不 unset($stmt)，很快触发 MySQL 的 max_prepared_stmt_count 上限（默认 16382），后续所有 prepare 报错 Commands out of sync 或 MySQL server has gone away，表面看是连接问题，实则是 statement 泄露。
- 循环内重复 prepare 同一语句，必须每次用完立刻
unset($stmt)，不能等 GC —— PHP 7.4+ 的 GC 延迟不可控 - 确认
wait_timeout（MySQL 默认 28800 秒）和应用层连接池空闲超时（如 Swoolemax_idle_time）严格对齐，否则连接被服务端断开，应用还拿旧连接调prepare，必然失败 - Swoole 协程环境下，PDO 实例和
PDOStatement绝对禁止跨协程共享，必须 per-request 从连接池取新实例 —— 它们不是协程安全的
真正难的不是写对一条 bindValue，而是在库存扣减、订单生成、优惠券核销等多个强一致性环节里，所有 SQL 路径都保持参数类型稳定、statement 及时释放、连接生命周期可控——漏掉任意一环，安全补丁就变成性能瓶颈。
