参数化查询本身不是性能瓶颈，而是性能优化起点；真正拖慢查询的是参数化后优化器因统计信息不准、索引不匹配或函数包装导致执行计划劣化。
参数化查询不是性能瓶颈，而是性能优化的起点——真正拖慢查询的，是参数化之后数据库优化器“猜不准”导致索引失效、执行计划劣化。优先用数据库端预编译（PREPARE/EXECUTE 或语言层 PreparedStatement），但必须配套索引与统计信息治理，否则安全换来了更差的响应。
为什么数据库端预编译比应用层拼接更稳
预编译语句在数据库服务端完成解析、绑定、计划生成，同一结构的查询可复用执行计划；而字符串拼接每次都要硬解析，CPU开销高、锁竞争强，还容易因空格/换行差异被当成新语句。更重要的是，数据库原生预编译能保留类型上下文（如 INT vs TEXT），避免应用层驱动隐式转换导致计划缓存失效。
- PostgreSQL 中显式使用
PREPARE stmt_name AS ...+EXECUTE stmt_name USING ...，计划缓存生命周期由会话控制，可控性强 - MySQL 8.0+ 的
PREPARE语句支持服务端计划缓存，但需确保prepared_statement_cache_size > 0 - Java 的
PreparedStatement底层仍走 JDBC 的prepareStatement()调用，是否真进数据库预编译取决于驱动配置（如 MySQL Connector/J 的useServerPrepStmts=true）
参数化后索引失效的三个高频原因
执行计划从 Index Scan 退化为 Seq Scan，不是参数化错了，是优化器没拿到足够信息做判断。常见触发点：
- 复合索引顺序与 WHERE 条件参数缺失不匹配：比如索引是
(tenant_id, created_at)，但查询只传了created_at = ?，前导列tenant_id未提供，索引直接跳过 - 字段上有函数包装：写成
WHERE UPPER(name) = ?，即使name有索引也无效；应建函数索引CREATE INDEX idx_users_name_upper ON users ((UPPER(name))) - 统计信息陈旧或基数估算失准：特别是枚举类字段（如
status IN ('active','pending')），若用单个参数IN (?)，优化器无法拆解值分布；改用IN (?, ?, ?)显式展开，或建扩展统计CREATE STATISTICS s1 ON status FROM orders
如何验证预编译是否真起效
不能只看代码写了 prepare，要确认执行路径和缓存行为是否符合预期：
- PostgreSQL：查
pg_prepared_statements确认语句已注册；用EXPLAIN (ANALYZE, BUFFERS)对比PREPARE后首次与后续EXECUTE的Planning Time是否显著下降 - MySQL：开启
performance_schema，查prepared_statements_instances表的EXECUTIONS计数；同时监控Com_prepare_sql与Com_execute_sql的增量比 - 警惕“伪预编译”：某些 ORM（如旧版 SQLAlchemy）默认关闭
native_bind，实际仍走字符串插值；检查生成 SQL 是否含?或$1占位符，而非拼出完整字符串
最易被忽略的一点：预编译语句的生命周期管理。连接池中连接复用时，若未显式 DEALLOCATE PREPARE 或重置会话，可能残留旧计划；高并发下大量未释放的 PREPARE 还会耗尽 max_prepared_statements 配额，导致后续请求降级为普通查询。这问题不在代码逻辑里，而在连接初始化和销毁钩子中。
