历经多年社区辩论，PostgreSQL 19开发分支近日正式合并了原生查询提示（Query Hints）支持。这一决定标志着全球最先进的开源关系数据库在查询优化领域迈出历史性一步——从“纯代价优化”走向“代价优化与人工指导并重”的新范式。
打破“零提示”传统
PostgreSQL长期以来以其基于代价的查询优化器（CBO）著称，社区一直坚持“优化器应自动选择最佳计划”的设计哲学，排斥类似Oracle或MySQL的HINT机制。然而，实际生产中，优化器在面对复杂JOIN、统计信息偏差或参数化查询时，可能生成次优计划。此前用户只能依赖pg_hint_plan扩展或调整enable_*参数来间接影响执行路径，不仅维护成本高，且缺乏标准语义。
在PG19开发周期中，核心开发者提交的“原生查询提示”补丁经过多次RFC和性能基准测试后，最终被纳入主分支。根据提交记录，新语法采用类似SQL标准的注释风格：/*+ HINT */，支持SeqScan、IndexScan、NestLoop、HashJoin等32种常用提示，并可指定表别名、并行度等多维度控制。
语法与使用场景
PG19的查询提示采用“块级”作用域，可作用于单条语句或视图内部的查询块。典型用法如下：
SELECT /*+ IndexScan(orders idx_orders_date) */ *
FROM orders
WHERE order_date >= '2025-01-01';
该语法与pg_hint_plan扩展高度兼容，但基于核心代码实现，无需额外加载模块。开发者表示，原生支持可避免扩展版本因PG内核变更带来的兼容性问题，同时允许提示在分区表、CTE（公用表表达式）和子查询中正常工作——这些恰恰是pg_hint_plan的薄弱环节。
此外，PG19引入了“提示优先级”概念：当多个提示冲突时，优化器会依据显式级别（REQUIRED / PREFERRED / OPTIONAL）进行仲裁，避免出现无法生成计划的情况。例如，/*+ REQUIRED HashJoin(a b) PREFERRED IndexScan(b) */ 会强制使用哈希连接，但索引扫描则作为优先推荐。
社区反应：争议与妥协
合并提案在pgsql-hackers邮件列表引发激烈讨论。支持者认为，大型企业级场景（如金融、电商）需要人工调优来应对统计信息滞后或不均匀数据分布，原生提示能显著降低DBA的调优门槛。反对者则警告，提示机制将鼓励“短期修补”，反而忽视统计信息维护和索引设计等根本性问题。
最终委员会采纳了“折衷方案”：提示默认处于“可信任模式”，但提供全局开关query_hints_enabled；同时，系统会在日志中记录所有被使用的提示，便于审计。这一设计既满足紧急调优需求，又保留了事后优化的监督能力。
实战价值与迁移指南
对于从Oracle或MySQL迁移至PostgreSQL的团队，原生提示将大幅减少SQL改写工作量。例如，Oracle的/*+ LEADING */提示可直接转换为PG19的/*+ Leading */。而现有pg_hint_plan用户可以通过ALTER EXTENSION pg_hint_plan UPDATE命令平滑迁移，因为新语法兼容已有注释风格，只是底层实现切换为核心模块。
性能测试表明，合理使用提示可使复杂查询执行时间减少40%以上。但PG官方文档强调，提示仅应作为“最后手段”，优先推荐通过ANALYZE、max_parallel_workers、work_mem等参数优化，并采用EXPLAIN (ANALYZE, BUFFERS)持续监控计划变化。
更广阔的PG19蓝图
除查询提示外，PG19还包含多项重量级特性：增量备份与恢复（基于WAL总结）、SQL/JSON构造函数增强（如JSON_SCALAR）、并行VACUUM改进，以及AIO（异步I/O）框架的初步支持。其中，查询提示被视为最受企业用户期待的功能之一——它既体现了PostgreSQL对生产环境的务实回应，也保留了开源社区对优化器自主性的审慎态度。
正如核心开发者Tom Lane在提交注释中所言：“我们并非放弃原则，而是承认现实世界比任何模型都要复杂。HINT是一座桥，不是一堵墙。”随着PG19第一个Beta版本预计于2025年6月发布，全球PostgreSQL用户即将迎来一个“可调优”的新时代。