参数化查询通过复用同一执行计划避免反复编译，1000次调用仅编译1次、cpu降约85%；但sql server存在参数嗅探问题，首次参数值决定缓存计划，导致后续不同选择性参数性能骤降，需用局部变量、option (recompile)或optimize for等策略平衡稳定性与开销。
参数化查询如何避免执行计划反复编译
大规模并发下，数据库最怕的是同一类查询每次传入不同值就重新解析、生成执行计划。比如 SELECT * FROM orders WHERE user_id = 123 和 SELECT * FROM orders WHERE user_id = 456，如果靠字符串拼接，SQL Server 或 MySQL 会当作两条不同语句处理，各自编译、各自缓存——1000 个用户并发，就可能触发 1000 次编译，CPU 直接拉满。
参数化查询把结构和数据彻底分开：SELECT * FROM orders WHERE user_id = @user_id 这条模板只编译一次，后续所有调用都复用同一个执行计划。实测数据显示，1000 次调用下，编译次数从 1000 降为 1，CPU 时间减少约 85%。
注意：这个优势依赖数据库的计划缓存机制，SQL Server 默认开启，MySQL 5.7+ 的 prepared_statement 模式也支持；但若在存储过程中用 EXEC(@sql) 动态拼接，哪怕带参数，也绕过了预编译，等于白做。
为什么参数化能天然防御 SQL 注入
注入的本质是“数据库把用户输入当代码执行”。比如用户输进 admin' OR 1=1 --，拼接后变成：SELECT * FROM users WHERE name = 'admin' OR 1=1 --'，注释符让密码校验失效。
而参数化查询中，@name 是纯数据容器，数据库在语法解析阶段就已锁定语句结构，运行时只把值代入占位符位置，不参与任何语法分析。哪怕传入 '; DROP TABLE users;--，它也只是被当作一个带单引号的字符串存进字段，绝不会触发额外语句。
这和手动转义（如 mysql_real_escape_string）有本质区别：后者依赖字符集、编码上下文，容易被双字节绕过；参数化是引擎层隔离，无需开发者操心过滤逻辑。
高并发下参数嗅探（Parameter Sniffing）反而成新瓶颈
SQL Server 默认会根据第一次执行时的参数值生成执行计划，并缓存复用。问题来了：第一次传的是 @min_price = 10（查出 1000 行），生成了索引扫描计划；第二次传 @min_price = 10000（只查出 2 行），本该走索引查找，却仍硬套扫描计划，性能暴跌。
常见应对方式包括：
- 在存储过程里对参数赋值给本地变量再使用，切断首次参数与计划绑定（
DECLARE @local_min_price DECIMAL(18,2) = @min_price） - 显式加
OPTION (RECOMPILE)，适合参数组合差异极大、执行频率不高的场景 - 用
OPTIMIZE FOR (@min_price = 100)引导优化器按典型值生成计划
MySQL 没有原生参数嗅探问题，但它的查询缓存（query_cache_type）在 5.7 已废弃、8.0 彻底移除——因为高并发下缓存键校验锁竞争严重，反而拖慢整体吞吐。
表值参数（TVP）是并发批量操作的关键突破口
当需要一次插入/更新上百条记录，传统做法是循环调用单条 INSERT，网络往返 + 事务开销巨大。用表值参数，可以把整个数据集打包成一张内存表传入：
CREATE TYPE dbo.OrderItemTableType AS TABLE (
product_id INT,
quantity INT,
price DECIMAL(18,2)
);
然后在存储过程中直接 INSERT INTO order_items SELECT * FROM @items。实测显示，100 条记录插入，网络往返从 100 次降到 1 次，事务持有时间缩短 90% 以上。
注意：TVP 在 SQL Server 中需提前建类型，且不能直接用于临时表或 CTE；MySQL 不支持 TVP，得用 JSON 参数 + JSON_TABLE() 替代，但性能和可读性打折扣。
真正难的不是写对单条参数化语句，而是理解执行计划怎么缓存、参数值如何影响计划质量、以及批量场景下数据载体该怎么选——这些细节在压测时才会暴露，上线前必须验证。
