这是一个关于postgresql数据库与sql相关优化的系列文章，目前已更新至第6篇。本文将详细探讨sql语句的执行过程。
SQL语句的执行过程分为几个步骤：
语法分析和词法分析：这是SQL语句的第一步，看似简单，但实际上非常复杂。例如，一个简单的SELECT语句可能包含许多参数和词法，需要从这里开始进行词法分析。
语义分析：这一步的主要功能是将复杂的SQL语句进行分割，为后续分析做准备，并生成原始解析树（raw parse tree）作为下一步的输入。
语句重写：在这一步，系统会对语句进行重写。你可以通过pg_rewrite查询表和视图的重写记录，以查看系统接收到的查询重写后的结果。
执行计划优化：根据重写后的信息，数据库系统通过优化器结合本地服务器的表统计分析信息，生成执行计划。这里将逻辑操作转换为物理操作，可能会将多个逻辑操作合并为一个物理操作。在构建执行计划时，会计算每个操作的成本，最终组合成多个执行方式并计算总成本，成本最低的方案被选为最优。成本估算的方式包括CBO（基于成本的优化）和RBO（基于规则的优化）。
执行：这是SQL语句的最后一步。PG可以通过explain命令展示语句的执行计划，从里到外、从下到上的方式展示执行顺序。也可以通过pgadmin展示图形化的执行计划。
需要解析的语句种类包括：
- select
- insert
- update
- declare cursor
- create as
- create materialized view
- refresh materialized view
- execute
POSTGRESQL使用操作系统中的工具Lex和yacc来处理这些操作，将DML与其他语句分开，对SQL中的关键字进行标识，并通过分析器的语法规则进行处理。
在早期或某些数据库中，对SQL语句的写法要求较高，这其实是由于第一步的语句重写功能较弱。对于强大的数据库系统，不同写法达到相同结果的SQL语句会被重写成一种方式，从而在生成执行计划时避免问题，优化引擎的工作也会更加准确，不会要求条件必须按特定顺序撰写。
以full scan, merge sort, hash join等多表算法为例，三个表的关联操作在没有条件的情况下，仅仅是连接操作就有9种连接方式，12种可能的连接顺序，整体执行计划可以考虑的方案就有339=108种。如果再加上WHERE条件，可能的执行计划方案可以轻松突破四位数。如果还有子查询，基于成本的优化算法依赖于最优性原则：最优计划的子计划对于相应的子查询是最优的。优化器从最小的子计划开始构建最优计划，这是一项非常耗费计算资源的工作，因此数据库会缓存执行计划，尽量对相同查询结构使用同一种执行计划方案。
执行计划方案得出后的成本计算是下一步。在PG的参数配置中，有针对tuple、index计算和IO性能提取的参数设置，这是一种开放的心态，信任用户可以在了解自己硬件性能的基础上，通过调整PG的系统计算基础成本数据，让SQL在计算时充分利用硬件，使用更合适的成本估算模式。
然而，这也会带来一些影响，即在用户不熟悉硬件和PG的情况下，不能充分发挥数据库本身的特性和性能优化特性。
实际情况更为复杂，下面两个查询语句仅仅是条件值发生了变化，整体的执行计划就发生了变化。因此，查询条件导致的数据量变化也是导致执行计划变化的一个原因。在某些数据库中，这会导致查询速度时快时慢，因为数据库使用了同一个执行计划去套用在不同条件的状态，造成了问题。
追究导致上述问题的原因其实是一个复杂的问题。你的统计分析信息是否正确？在正确的情况下，系统会根据条件数据的数量来分析使用INDEX还是FULL SCAN哪种方式更有利，最终导致判断COST在不同条件下值的不同。
通常情况下，数据库会根据已有的统计分析数据以及自己定义好的CBO来对产生的执行计划进行COST评估，这也是目前大多数商业数据库采用的方案之一。
参考文章：
