参数化查询是防御sql注入的底线，性能下降主因是优化器缺乏参数信息导致索引失效；需通过函数索引、更新统计信息、调整复合索引顺序、避免隐式转换等手段保障执行计划稳定。
SQL注入防御必须用参数化查询，但参数化后查询变慢怎么办
参数化查询是防御SQL注入的底线，不是可选项。但很多团队在把拼接SQL改成PreparedStatement（Java）或pg_query_params（PostgreSQL）后，发现执行计划变差、响应延迟上升——问题通常不出在“用了参数化”，而出在数据库没拿到足够信息来生成最优执行计划。
WHERE条件中使用参数时，索引失效的常见原因
数据库优化器无法预知参数值，可能放弃使用索引，尤其当字段选择性低、统计信息陈旧或存在函数包装时。典型表现是执行计划里出现Seq Scan而非Index Scan，哪怕字段上有索引。
- 字段有索引，但查询写成
WHERE UPPER(name) = ?：函数导致索引不可用，应建函数索引（如CREATE INDEX idx_name_upper ON users ((UPPER(name)))） - 参数值分布极不均匀（如
status字段 95% 是'active'），优化器预估走索引成本更高，直接全表扫——此时需用SET enable_seqscan = off临时验证，但生产环境应靠CREATE STATISTICS或更新统计信息解决 - 复合索引顺序与参数位置不匹配，例如索引是
(tenant_id, created_at)，但查询只传了created_at = ?，而没传tenant_id：跳过前导列，索引失效
如何让参数化查询稳定命中索引
核心思路是“帮优化器做对的选择”，而不是绕过参数化。
- 确保查询中所有参数列都有对应索引，且复合索引的前导列是查询中必填（非NULL）的高选择性字段
- 定期运行
ANALYZE table_name（PostgreSQL）或UPDATE STATISTICS（SQL Server），尤其在大批量数据导入后 - 对固定枚举类参数（如
type IN ('A','B')），避免用IN (?)单参数，改用多个参数：IN (?, ?, ?)，否则优化器无法估算基数 - 必要时用查询提示（如 PostgreSQL 的
/*+ IndexScan(t idx_t_status) */），但仅限已确认执行计划错误且短期无法调优的场景
参数化 + 索引优化后的性能验证要点
不能只看平均耗时下降，要盯住长尾和执行计划稳定性。
- 用
EXPLAIN (ANALYZE, BUFFERS)对比改写前后的真实执行路径，重点关注Rows Removed by Filter是否大幅增加（说明过滤下推失败） - 检查缓存命中率：参数化后同结构查询可复用执行计划，但若绑定变量类型不一致（如
INTvsTEXT），可能触发隐式类型转换，导致计划缓存失效 - 监控
pg_stat_statements中同一查询文本的calls和total_time，确认是否真正在复用计划，而非每次都在硬解析
user_id = ? 在大多数情况下走索引很快，但某几个超级大客户的数据量占全表 40%，这时就得考虑分区或单独路由逻辑。
