预编译语句通过缓存执行计划提升性能与安全性，适用于高频执行、参数化查询及复杂SQL场景，但应避免用于单次或动态SQL，需合理管理生命周期与数量。
在使用 PostgreSQL 时，预编译语句（Prepared Statements）是一种提升性能和安全性的有效手段。但并不是所有场景都适合使用。了解何时启用以及如何正确使用预编译语句，是优化数据库交互的关键。
什么是预编译语句？
预编译语句是将 SQL 模板提前发送给数据库服务器进行解析、重写、计划生成并缓存执行计划的过程。后续执行只需传入参数，复用已准备好的执行计划，避免重复的解析和优化开销。
在 PostgreSQL 中，通过 PREPARE 和 EXECUTE 命令来使用：
PREPARE get_user_by_id(int) AS
SELECT * FROM users WHERE id = $1;
EXECUTE get_user_by_id(123);
大多数现代客户端驱动（如 libpq、JDBC、psycopg2、Npgsql 等）也支持自动管理预编译语句，尤其是通过参数化查询接口。
何时应使用预编译语句？
以下情况推荐使用预编译语句：
- 高频执行相同结构的 SQL：比如在循环中反复执行 INSERT 或 SELECT，仅参数不同。预编译可显著减少解析和规划时间。
- 防止 SQL 注入攻击：预编译语句天然隔离代码与数据，是防御注入的最佳实践之一。
- 复杂查询的稳定执行计划：对于耗时较长的复杂查询，预编译能固定执行计划，避免每次执行因参数变化导致选择低效路径（但也需注意“参数嗅探”问题）。
- 连接池环境下的资源复用：在应用服务器频繁执行同类操作时，配合连接池使用预编译可降低数据库负载。
何时不应使用？
尽管有优势，但滥用预编译也可能带来问题：
- 只执行一次的查询：预编译本身有开销（解析、计划、内存维护），单次执行反而更慢。
- 动态结构的 SQL：如动态列、表名或 WHERE 条件结构变化，无法有效复用执行计划。
- 过多不同的预编译语句：PostgreSQL 会为每个预编译语句保留执行计划，数量过多会消耗大量内存（特别是在会话级缓存中）。
- 参数敏感性导致计划失衡：如果某条语句对参数值高度敏感（例如某些值走索引，某些走全表），预编译可能固化一个不适合所有参数的执行计划。
最佳实践建议
为了最大化收益并规避风险，遵循以下原则：
- 优先使用参数化查询而非字符串拼接：即使不显式 PREPARE，大多数驱动在后台会智能处理简单参数化查询，兼顾安全与效率。
- 对核心业务高频 SQL 显式预编译：如订单创建、用户查询等，可在连接初始化后准备关键语句。
- 控制生命周期和数量：使用完及时通过 DEALLOCATE 释放，避免长期占用内存。
- 监控执行计划是否合理：使用 EXPLAIN EXECUTE 查看实际执行路径，确认未因预编译导致性能下降。
- 结合应用程序层缓存考虑：极高频读取可考虑先查缓存，而非依赖数据库预编译。
基本上就这些。预编译不是银弹，但在合适场景下，它是提升数据库响应速度和系统安全的重要工具。关键是根据访问频率、SQL 结构稳定性及参数特征做出判断。不复杂但容易忽略。
