pdo::prepare()在秒杀中变慢甚至失效，根本原因是默认开启pdo::attr_emulate_prepares=true导致sql在php层拼接、未发往数据库，执行计划无法复用；必须关闭模拟预处理、显式绑定类型、隔离动态标识符、限制连接资源，否则缓存失效、执行计划退化、连接堆积三者叠加引发雪崩。
高并发秒杀场景下，SQL性能与防注入不能靠“加个参数化”就一劳永逸——必须关闭模拟预处理、显式绑定类型、隔离动态标识符、限制连接资源，否则缓存失效、执行计划退化、连接堆积三者叠加，系统会在峰值时直接雪崩。
为什么PDO::prepare()在秒杀里可能变慢甚至失效
不是PDO::prepare()本身有问题，而是默认开启的PDO::ATTR_EMULATE_PREPARES = true让它根本没发到数据库。PHP 在本地拼 SQL，每次请求都硬解析，执行计划无法复用。你在 pg_stat_statements 里会看到同一语句 calls 极低但 total_time 奇高；EXPLAIN ANALYZE 显示反复生成新计划，甚至退化成 Seq Scan。
- 必须显式关闭模拟预处理：
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false) - DSN 中强制指定字符集：
mysql:host=xxx;dbname=xxx;charset=utf8mb4，否则'123'和123被当成不同类型，触发隐式转换 - 数字类参数不用
execute([$value])，改用bindValue($param, $value, PDO::PARAM_INT)——PHP 对null或字符串'0'的类型推断在 7.4+ 之后不稳定
WHERE条件写法如何让索引在秒杀中不掉链子
参数化不等于自动走索引。秒杀查询常因写法不当让优化器“看不见”索引，尤其在 WHERE stock > ? 这类判断上。
- 避免对字段加函数：
WHERE UPPER(name) = ?→ 改成WHERE name = LOWER(?)，并建函数索引CREATE INDEX idx_name_lower ON users ((LOWER(name))) - 复合索引顺序要匹配查询模式：如果索引是
(item_id, version)，但秒杀只传item_id = ?，那就没问题；若只传version = ?，索引完全失效 -
IN子句不能只用一个占位符：IN (?)是非法且低效的，必须展开为IN (?, ?, ?)，否则优化器无法估算基数，倾向全表扫
表名/字段名/ORDER BY 等动态部分怎么防注入
? 占位符只接受值（value），不支持标识符（identifier）。任何把用户输入拼进表名、字段名、排序方向或 LIMIT 偏移量的操作，都是开门揖盗。
-
ORDER BY ?语法错误，MySQL 直接报ERROR 1064；必须用白名单映射：$allowed_sorts = ['created_at', 'price']; $sort = in_array($_GET['sort'], $allowed_sorts, true) ? $_GET['sort'] : 'created_at'; - 动态表名如分库分表后缀
orders_202609，必须正则校验：preg_match('/^orders_\d{6}$/', $table)，且仅允许预定义格式 - 模糊查询安全写法是
WHERE name LIKE CONCAT('%', ?, '%')，其中?仍受参数化保护；但别写成WHERE name LIKE '%'.$_GET['q'].'%'
秒杀请求暴增时，连接和语句生命周期怎么管
每笔秒杀请求都要建连接、prepare、execute、fetch、close。漏掉任意一环，max_prepared_stmt_count 就会打满，后续所有 prepare 都失败，报错 Commands out of sync 或 MySQL server has gone away。
- 每次
prepare后，用完立刻unset($stmt)，别等 GC；循环内重复 prepare 同一条语句却不 unset，MySQL 侧句柄累积，达到上限即拒绝新 prepare - 确认应用层空闲连接超时与 MySQL 的
wait_timeout一致，否则连接被服务端断开，应用还拿旧连接调prepare()，必然失败 - 在 Swoole 或协程环境，禁止跨协程共享
PDO或PDOStatement实例——必须 per-request 新建或从连接池取隔离实例
最易被忽略的是：参数化能防注入，但挡不住高权限账号被利用。秒杀接口连的数据库账号，只应有 SELECT ... FOR UPDATE 和 UPDATE 权限，绝不能有 DROP、FILE、PROCESS。否则攻击者一旦突破其他入口，就能绕过所有 SQL 层防护直接拖库。
