优化器是关系数据库的核心和灵魂。它分析 SQL 语句并确定满足每个语句的最有效的执行计划。对于数据库的优化器，在数据库行业里面，一直都有很多形形色色的声音。

很多 Oracle 的 DBA，都沉醉于 Oracle 数据库强大的 SQL 优化能力。对于同样的 SQL 语句，即便编写比较粗糙，它也能够给你生成比较高效的执行计划。在他们习惯了 Oracle 优化器这种很智能的行为后，很难去接受别的关系型数据库产品。对于 SQL 的优化，Oracle 还提供了很多用于调整执行计划的接口，比如：带有执行计划提示的 SQL 注释，在线调整 SQL 执行计划的 SQL Profile。

而对于那些熟悉了 MySQL 的 DBA 或者开发人员，他们几乎很少关心优化器，甚至都可能没有感知到优化器在数据库里面的存在。对于 SQL 优化，他们一般会看看有没有选择正确的索引；而对于表连接的 SQL，他们的建议是，应用开发的时候干脆就别用了。实际上，MySQL 的早期版本都没有优化器，就是解析完 SQL 语句就开始执行了。

PostgreSQL 数据库拥有完整的优化器，大部分情况下，对于复杂的 SQL 都可以确定比较高效的执行计划。但是，和 Oracle 一样，也会存在优化的盲点。总之，PostgreSQL 优化器的行为也是简单且易于理解的，对于一条 SQL 语句，根据数据库收集到的各方面的统计信息，在用户可接受的时间内，确定它认为的最高效的执行计划。当你发现某一条 SQL 语句的性能较差，那就分析这条 SQL 的执行计划，并重写 SQL 语句，让数据库能生成更加高效的执行计划。

PostgreSQL 社区一直在持续改进数据库的优化器。当您发现存在优化盲点的 SQL 语句后，最好的做法是将它报告给社区。社区有很多优化器方面的专家，他们会针对报告的问题给出详细和充分的意见，讨论的周期可能会持续很长时间，期间需要进行反复的测试验证和分析讨论。这种充分的讨论是很有必要的，因为优化器的细微调整，可能会给其他情况的 SQL 语句带来一些意料之外的影响。

那么，PostgreSQL 数据库是否需要像 Oracle 一样更进一步，提供一些用于调整执行计划的接口呢？

整体来看，这类调整执行计划的接口，都更像是一些用于优化应用性能的奇技淫巧。它们跟应用软件开发过程中的其他技巧一样，没有太多区别。比如：

• 在软件开发过程中，你可以将一段代码逻辑以汇编语言的方式实现，让应用获得更优的运行性能；
• 采用一些特定于某类 CPU 架构的特定指令，来实现具体的代码逻辑；
• 采用一些特定于某操作系统的特定接口，来实现具体的业务功能；

这类可用的技巧很多，但是它们都会给应用软件带来一个典型的问题：你的应用软件的通用性/平台兼容性很差。

想想你的应用软件的部署，部署完后还需要在数据库中配置 SQL Profile。更麻烦的是，这些配置可能都是 DBA 临时手工修改的，甚至他们自己都忘了做过哪些修改。对于那些带有执行计划提示的 SQL 注释，随时可能因为数据库的版本升级，发生一些预料不到的行为变更。这样的结果，对应用软件的发展，会带来很坏的影响。

想到这些问题，也许你可能就明白了，为什么 PostgreSQL 数据库没有提供这样一些用于调整执行计划的接口。即使 PostgreSQL 社区有像这样的插件，通过 SQL 注释指示执行计划的选择，这样的特性也很难会被社区接纳和合入到内核。