预编译sql在高并发下更难被注入，因其服务端对同一结构语句仅解析一次并复用执行计划，参数值全程不参与语法分析，恶意输入如' or 1=1 -- 仅作字符串字面量处理；但表名、字段名等非值位置仍需白名单校验。
预编译SQL在高并发下为何更难被注入
因为数据库服务端对同一结构的 PREPARE 语句只做一次解析和执行计划生成，后续所有 EXECUTE 都复用该计划——参数值全程不参与语法分析，攻击者输入的 ' OR 1=1 -- 这类内容只会被当作字符串字面量塞进 WHERE 条件，不会触发逻辑篡改。
字符串拼接在高并发时放大注入风险
每次请求都生成新 SQL 字符串，数据库必须硬解析整条语句。这时只要两个请求的输入导致最终 SQL 字符串有细微差异（比如空格数、换行位置不同），就会被当成全新语句重新编译，不仅性能崩，还让 WAF 或审计规则更难识别恶意模式。
- 用户输入
admin'--和admin' --（多一个空格）拼出的 SQL 被视为两条不同语句 - 应用层若未统一 trim / normalize 输入，就等于主动制造绕过条件
- 高 QPS 下，这类“语义相同但字符串不同”的请求会快速冲垮共享池（Shared Pool）
预编译不是万能：哪些地方仍可能漏防
占位符 ? 只能用于值（value），不能用于表名、字段名、排序方向或 LIMIT 偏移量。这些位置若依赖用户输入，仍需白名单校验或枚举映射，否则用 ${} 或字符串拼接就等于开门揖盗。
-
ORDER BY ?是非法语法，MySQL 会报错ERROR 1064 - 模糊查询中写
WHERE name LIKE ?是安全的，但若写成WHERE name LIKE CONCAT('%', ?, '%')，则?仍受保护 - 动态表名必须走配置项查表或正则匹配（如只允许
^user_\d{4}$），不能靠参数化兜底
性能差异在高并发下直接变成安全瓶颈
硬解析消耗 CPU 和 latch 争用，尤其在 OLTP 场景下，大量并发连接同时触发硬解析会导致 library cache lock 等待飙升。这时运维可能为保响应时间临时关闭统计信息自动收集或禁用计划缓存，结果是：安全机制还在，但数据库自己把优化器搞瘸了，反而让某些边界 case 的执行计划退化到全表扫描——数据没被注入，却被批量拖走。
真正容易被忽略的是：预编译的防护效力，高度依赖数据库是否开启并维护好统计信息。没有直方图、过期的索引基数，会让本该走索引的 WHERE id = ? 强制走全表扫描——这不是漏洞，但会让“防住注入”变得毫无意义。
