深入PostgreSQL SQL执行链路：从解析到慢SQL排查

查过几十次慢SQL之后，我最深的感受是：很多人并不是不会写SQL，而是不了解PostgreSQL在执行一条SQL时究竟走了哪些路。同样的SELECT，在A库上跑3毫秒，换到B库变成3秒，中间差出来的往往不只是数据量，而是执行计划、缓存命中率、锁等待甚至统计信息新鲜度这些看不见的因素。

这篇是“PostgreSQL SQL语句的执行过程”系列的第二篇。上一篇把SQL从客户端到服务端的过程带到了解析和计划生成的门口，这篇我们继续往里走，重点聊清楚三件事：

• 一条SQL从文本变成执行计划，中间经历了解析、分析、重写、规划、执行这几个阶段，每个阶段各自在做什么；
• 执行引擎拿到计划之后，如何在表、索引、缓存、内存之间来回倒腾，最终把结果一行行返回给你；
• 以及当SQL变慢、会话卡住、锁文件报错时，应该从执行链路的哪个环节下手排查。

同样一篇文章，看懂“执行过程”只能算入门，能在生产环境里顺着链路定位问题才算真正吃透。这篇文章尽量把复杂的机制讲得落地一点，配合实际案例和排查经验，适合正在学习PostgreSQL的开发者，也适合被慢SQL折磨过的DBA和后端工程师。

1. 一条SQL进门之后，服务端到底做了什么

1.1 从“纯文本”到“可执行程序”的三站路

PostgreSQL的架构是经典的“服务端进程+共享内存”模型。你在客户端敲下一条SQL，按回车，服务端会有一个后台进程（backend process）接收这段文本。接下来的处理流程可以概括成一句话：文本先进解析器，再进分析器，然后过重写器，最后交给计划器和执行器。

很多人容易把“解析”和“分析”混在一起。用生活里点外卖类比：

• 解析器相当于前台接单员，只看你的订单格式对不对。你写“要一份宫保鸡丁盖饭”，它负责把这句话拆成“动词+名词+数量”这样的结构，但完全不知道宫保鸡丁是什么。
• 分析器相当于后厨备菜师傅，它知道鸡丁要切多大、花生米要炸到什么程度。对应到数据库里，分析器会检查表是否存在、列是否存在、数据类型是否匹配。

在PostgreSQL源码中，解析之后会产生一棵解析树（parse tree），这个阶段的产物是RawStmt和SelectStmt这类结构。等分析阶段结束，解析树会被转换成查询树（Query tree），查询树是后续所有处理的基础数据结构，里面已经有语义信息了。

如果你写过简单的语法解析器就会知道，解析阶段的报错通常很直白：语法错误、关键词拼错、括号不匹配。分析阶段的报错则更偏语义化：表不存在、字段不存在、函数不存在。实际使用中，这里有一个容易踩的坑：PostgreSQL对大小写敏感的处理。未加引号的标识符会被自动折叠成小写，如果你建表时用了大写表名，查询时没加双引号，就会报“relation does not exist”。这个错误经常让新手误以为表丢了，其实只是在解析阶段，表名被统一成了小写而已。

1.2 分析器：做语义检查，也做表达式展开

分析阶段结束后，PostgreSQL会得到一个已经“消毒”的查询树。这时候还没完，还有一个容易被忽略的动作：把视图展开，以及把函数调用、表达式递归处理成可计算的形式。

举个例子，你查询时写了：

sql复制SELECT id, name FROM user_view WHERE create_time > now() - interval '1 day';

其中user_view是一个视图，内部可能关联了三张表。分析器会先解析视图定义，然后把这个视图引用改写成底层的子查询或者连接树。同理，now() - interval '1 day'这样的表达式会被组织成表达式树，在执行阶段逐行求值。

这里插一个实战经验：如果视图层级嵌套过深，分析阶段的耗时也会明显上升。我曾经优化过一个接口，SQL本身不复杂，但视图套了四层，每次执行光分析就花了几十毫秒。解决方法并不复杂，把多层视图拆成中间表，或者用LATERAL子查询替代部分嵌套，响应时间立刻降下来了。

分析阶段的性能问题平时不明显，但对高频短查询影响极大。一条查询每秒执行上千次，分析多花5毫秒，整体压力就会显著增加。这就是为什么很多团队要求把常用查询写成预处理语句（PREPARE）的原因之一，因为预处理语句可以跳过重复的分析和计划生成。

1.3 重写规则：不只是视图的内衣

接下来进入重写阶段（Rewrite）。PostgreSQL的规则系统非常强大，视图本质上就是一种规则。你可以用CREATE RULE自定义规则，也可以利用物化视图的自动刷新机制。但对99%的开发场景来说，重写阶段最重要的任务是处理视图和安全性。

规则系统会让查询树发生变换。还是用刚才的user_view举例，重写阶段会把视图引用替换成对应的SELECT语句。如果视图定义中有聚合、连接、排序，重写后的查询树会变得比原始语句复杂很多。这也是为什么一条看起来很简单的“查询视图”的SQL，执行计划却可能包含多个表扫描和聚合操作。

值得一提的是，PostgreSQL的规则系统和中台的“拦截器”并不一样，它是在查询树上做替换，而不是像触发器那样针对每一行触发。如果你需要审计某张表的读写，别指望用规则系统替代触发器，规则系统本身不面向逐行处理，逐行逻辑应该用触发器函数去实现。

重写完之后，查询树才真正到达优化器面前。优化器要做的事情，本质上就是回答一个问题：在满足SQL语义的条件下，用哪种方式拿数据最划算。

2. 计划器和执行器都做了哪些看不见的取舍

2.1 代价模型：为什么全表扫描不一定比索引扫描差

PostgreSQL的优化器是典型的基于代价的优化器（CBO）。所谓代价，不是指CPU耗时，而是一个无量纲的估算值。它综合了顺序扫描的块数、索引扫描的选择率、连接操作的中间结果大小等多个因素。

默认情况下，执行计划的代价公式大致如下：

text复制总代价 = 启动代价 + 运行代价
启动代价 = 找到第一行数据前需要付出的代价（例如排序可能需要先把全部数据读入内存）
运行代价 = 获取所需全部数据的总代价

你可能会惊讶于一个事实：当查询需要返回表中很大比例的行时，优化器宁可走全表扫描（Seq Scan），也不走索引扫描（Index Scan）。原因在于，索引扫描需要随机I/O访问堆表（Heap），如果结果集覆盖了表中20%以上的行，随机I/O的成本大概率超过顺序读全表。

有一次我在测试环境里看到一条SQL，明明WHERE status = 1字段上有索引，但执行计划选择了全表扫描。开发同学第一反应是“索引失效了”。我让他查了一下status=1的行数比例，占了整张表的60%，这种情况走索引反而更慢。后来把SQL改成按时间范围先过滤，再用status做二次过滤，执行计划才乖乖走了索引。

所以遇到“有索引但不走”的情况，不要急着加enable_seqscan=off这类参数强扭，先把统计信息看明白了再说。偶尔确实存在统计信息陈旧导致计划走偏的情况，那属于另一类问题，后面会讲到。

2.2 连接顺序和扫描方式的选择

当SQL里出现多表JOIN时，优化器的工作量会成倍增加。PostgreSQL会对连接顺序做枚举，通过动态规划或者遗传算法寻找代价最低的连接树。

JOIN的实现方式主要有三种：

• Nested Loop Join：适合小表驱动大表，驱动表每一行去匹配被驱动表；
• Hash Join：先把一侧表加载到内存建立哈希表，再扫描另一侧去匹配；
• Merge Join：两侧都按连接键排序，再做有序合并。

三种方式没有绝对的好坏。Nested Loop在连接键有索引时非常高效；Hash Join适合等值连接且一侧数据量较大时；Merge Join适合连接键本身已经排好序的场景，比如两张表都来自索引扫描。

这里有一个很多人忽略的关键点：执行计划里的JOIN顺序，并不一定等于SQL里写的顺序。比如：

sql复制SELECT *
FROM big_table b
JOIN small_table s ON b.user_id = s.user_id;

即使你把big_table写在前面，优化器如果判断“小表做大表驱动表更优”，依然会先扫描small_table，再对big_table做索引查找。所以在分析执行计划时，不要盯着SQL里的书写顺序，要以计划节点树为准。

计划树的最底层通常是表扫描节点，往上依次是连接节点、过滤节点、聚合节点、排序节点，最顶层是输出节点。你会看到执行计划从下往上读的排版形式。自己阅读时，建议把注意力放在代价最大的节点上，那往往是性能瓶颈所在。

2.3 参数和计划缓存：同一句SQL，两次执行可能不一样

优化器的另一个重要决策点是参数化。如果把查询条件写成普通SQL，每次执行都要重新做一遍计划。如果使用PREPARE语句或者服务端预处理，优化器会拿到参数值后做一次计划，之后复用这个计划。

PostgreSQL在处理预处理语句时有一个细分行为：第一次执行时通常会生成custom plan（按当前参数值定制），后续执行时如果优化器认为特定参数值对计划影响不大，就会切换到generic plan（通用计划）。generic plan不会依赖具体参数值，好处是稳定，坏处是如果第一个参数恰好落在选择性很强的范围，而后续参数范围很宽，通用计划可能不是最优的。

这个问题在动态SQL里更容易踩雷。使用一些ORM框架，如果开启了预处理语句，也要留意执行计划是不是被意外固定了。通常可以通过调整plan_cache_mode参数，让它更倾向于custom plan或者generic plan。

还有一类问题是“同样的SQL，参数不同，执行时长差百倍”——这种通常不是计划缓存的问题，而是数据分布倾斜。比如WHERE order_status = $1，传入“已完成”和“已取消”两个值时，结果集大小天差地别，但通用计划只选择一种策略。真要精细化处理，可以把这类SQL拆成两条，或者改用不同值域的物理表分区。

3. 执行器如何“逐行”把结果一股股吐出来

3.1 火山模型和Tuple Table Slot

优化器最终输出一棵计划树，但这棵树还“不能跑”。真正负责跑起来的是执行器（Executor）。PostgreSQL执行器采用经典的火山模型（Volcano Model），也叫迭代模型。每个计划节点都实现了一个迭代接口，上层节点调用下层节点获取一行数据，下层节点再调用下下层。

每一行数据在执行器里用TupleTableSlot结构表示。这个结构有点像流水线上的托盘，一行数据从表扫描节点取出后放进slot，传递给过滤节点，再传给连接节点，最后传递到输出节点。使用slot的好处是尽量减少数据拷贝，同一块内存可以在不同节点之间反复利用。

初学者看执行计划时，经常忽略“行数估算”和“实际行数”之间的差别。在EXPLAIN ANALYZE的结果中，rows这一列是优化器的估算值，actual rows是执行时的真实值。估算值和实际值差距过大，通常意味着统计信息不准，或者WHERE条件里的表达式无法被准确估算选择率。

3.2 常见执行节点是怎么工作的

拿一个简单的单表查询来说：

sql复制SELECT * FROM users WHERE age > 30 ORDER BY create_time DESC LIMIT 10;

执行计划里大概率会出现这样的节点：

• Seq Scan 或 Index Scan：负责读取满足age > 30的行；
• Sort：对结果按create_time做排序；
• Limit：取排序后的前10行。

这些节点的配合方式可能和直觉不同。如果表上有一个(age, create_time)的复合索引，优化器可能会选择Index Scan，由于索引内部是按(age, create_time)有序的，排序节点甚至可以省略。这就是创建一个顺序合理的“复合索引”能同时加速过滤和排序的原因。

如果你发现执行计划里出现了Sort节点且排序量很大，先检查能否让索引天然提供有序结果。否则就要看work_mem够不够，排序超过work_mem时，PostgreSQL会溢出到磁盘临时文件，性能会直线下降。“Everything should be made as simple as possible, but not simpler”——排序这个动作，能省则省。

Hash Join节点的工作方式值得多说一句。它会在内存里为左侧（通常是外表）建立哈希表，然后扫描右侧表，用连接键的哈希值快速找到匹配行。如果建立哈希表的数据量超过work_mem，就会分批写入临时文件。这里会看到“batches”参数从1变成大于1，这个数字一旦变大，几乎可以断定Hash Join因为work_mem不足，触发了多批次落盘。

3.3 执行过程中的缓存和内存协同

很多慢SQL不是慢在磁盘读了多少行，而是慢在缓存没命中。PostgreSQL的共享缓冲区（shared_buffers）负责缓存数据页，默认值通常是128MB。如果一条SQL需要的数据页全在shared_buffers里，执行时基本不涉及物理I/O；如果大量数据页不在缓存中，执行器就只能从操作系统或者磁盘拉数据页。

除此之外，PostgreSQL还有一层“关系缓存”和“系统目录缓存”，分别缓存表结构和系统表。第一次访问某张表时，需要从系统表读取表的元数据、字段信息等；第二访问时如果结构没变，就会直接走relcache缓存。这也是为什么连接池场景中，第一次执行总比后面慢一些。

这里给出一个生产实践常用的计算公式：

• shared_buffers建议设置为机器物理内存的25%左右；
• effective_cache_size建议设置为机器物理内存的50%~75%，这个参数会影响优化器对索引扫描代价的判断；
• work_mem不要设置太大，这个参数是“单次排序/哈希操作”可用的内存，如果连接数很多，每个连接都可能分配这么多内存，总量很容易爆。

我见过有人把work_mem调成2GB，以为能让排序更快，结果高峰期几十个会话同时排序，内存直接被打爆，进程被OOM Killer干掉。正确做法是先在单个会话里SET work_mem = '512MB'，对这条重SQL做测试，再决定是否全局调整。

3.4 统计信息：优化器做判断的“视力表”

优化器估算行数时依赖的是pg_statistic中存储的统计信息。PostgreSQL通过ANALYZE命令采样表数据，生成直方图、最常见值列表等统计信息。如果表数据发生剧烈变化，但统计信息长时间不更新，优化器就会“看不清”。

有个典型案例：某表平时只有几千行，某天业务方突然灌入几百万行数据，但没有执行ANALYZE。优化器依然以为这张表很小，于是选择全表扫描，结果一次查询扫了几百万行，线上接口直接超时。解决办法也很简单，大批量数据导入后执行：

sql复制ANALYZE table_name;

如果希望自动化，可以调整autovacuum相关参数，让PostgreSQL在数据变更量超过阈值后自动做analyze。一般默认阈值是20%的行数变化量，对于频繁大量导入的表，可以单独调整autovacuum_analyze_scale_factor。这里建议对核心大表单独设置较小的scale factor，让统计信息更敏感一些，代价是analyze会更频繁，但能显著减少计划跑偏的概率。

4. 权限、锁和并发体验是怎么影响“执行过程”的

4.1 权限校验发生在哪一步

PostgreSQL的权限校验并不是在执行计划最末端做的。当语句进入分析阶段并生成查询树后，会调用权限检查函数去确认当前用户是否有对相应表的SELECT、INSERT、UPDATE或DELETE权限。这个检查发生在优化器和执行器之前，所以没权限的用户在尝试执行时，往往还没走到生成计划那一步就会收到权限不足的报错。

权限控制还包括行级安全性（RLS）。如果表上启用了行级安全策略，最终生成的查询树会额外附加安全策略条件，在执行器扫描时逐行过滤。实现方式其实就是在政测条件上加了隐式WHERE条件。这对执行计划有一定影响：原本能走索引的过滤条件，因为附加了策略条件，选择率会变化，plan也可能跟着变。

实际调优时，如果一条SQL在超级用户下执行很快，换成普通用户执行却明显变慢，可以优先检查是否启用了RLS，以及策略里的条件是否命中索引列。我曾经遇到过一个案例，普通用户查询时执行计划里多了一个看起来规模巨大的子查询，那就是RLS策略引起条件重写造成的。后来优化了RLS策略的过滤方式，性能才恢复。

4.2 锁等待会让查询一直停留在“执行中”吗

执行器在工作时，会根据语句类型获取对应的锁。普通的SELECT获取的是ACCESS SHARE锁，UPDATE、DELETE会获取ROW EXCLUSIVE锁。做DDL操作，比如ALTER TABLE，会获取ACCESS EXCLUSIVE锁。ACCESS EXCLUSIVE锁会阻塞几乎所有其他操作。

发生锁冲突时，查询并不会立刻失败，而是进入等待状态。从应用层看，SQL一直卡在那里没返回；从数据库层看，pg_stat_activity里能看到这条查询的状态是active，并且wait_event_type是Lock。这种现象经常被误认为是SQL本身慢，实际上它连真正的执行都没跑完，在等锁释放。

排查锁问题，我一般直接执行这条：

sql复制SELECT pid, state, wait_event_type, wait_event, query_start, now() - query_start AS duration
FROM pg_stat_activity
WHERE state = 'active' AND wait_event IS NOT NULL;

配合pg_locks视图，可以进一步看到哪个事务持有了锁，哪个会话在等待。处理锁的最佳手段还是业务层面尽量减少长事务，尤其是不要在一个事务里先做复杂计算再提交，或者把多张大表的写入放在一个长事务里。

4.3 服务端启动时的“无法创建锁文件”迷局

另一个常见问题是PostgreSQL启动时报错：

text复制FATAL:  could not create lock file "/var/run/postgresql/.s.PGSQL.5432.lock": Permission denied

这个报错虽然发生在启动阶段，但和SQL执行链路也有关系——数据库进程根本起不来，后续SQL自然无从执行。原因通常是启动PostgreSQL的操作系统用户对/var/run/postgresql目录没有写权限，或者该目录被改成了root属主。

排查时先看目录属主：

bash复制ls -ld /var/run/postgresql

正常情况下应该是postgres用户所有。如果不对，可以用root修正：

bash复制chown -R postgres:postgres /var/run/postgresql

如果使用了Docker运行PostgreSQL，容器内系统用户UID可能与宿主机不一致，也会导致挂载目录权限错乱。解决思路是保证容器内运行用户对数据目录和socket目录都有读写权限，必要时指定--user参数或用user.namespace映射。

4.4 事务隔离级别如何影响结果可见性

执行一条SELECT时，它能读到什么数据，由当前事务的隔离级别决定。PostgreSQL默认隔离级别是Read Committed，每次语句开始时会获取一个新的快照；如果使用Repeatable Read或Serializable，则在整个事务内使用同一个快照。

快照机制基于MVCC。在执行器读取每一行数据时，会检查该行的事务可见性：如果产生这行数据的事务在快照之后提交，当前语句就看不到；如果事务尚未提交，也看不到。这个判断发生在每一行读取时，也就是行级可见性判断。

由于MVCC的可见性检查和多版本数据存在，旧版本数据不会立即删除，而是留在页面中。当大量更新或删除发生时，表会产生膨胀（bloat），查询时要扫描的数据页明显变多。定期VACUUM是必须的。一个没有打开autovacuum的数据库，表膨胀速度会非常惊人，查询性能会从“毫秒级”退化到“秒级”，执行计划还看不出明显问题。

5. 排错实战：从执行计划到慢SQL治理

5.1 EXPLAIN与EXPLAIN ANALYZE到底该怎么读

分析执行过程时，最直接的工具是EXPLAIN。很多人习惯只用EXPLAIN，但只展示计划不执行。如果不看实际执行时间和实际行数，很多判断都只是猜测。

推荐使用这样的语句：

sql复制EXPLAIN (ANALYZE, BUFFERS, VERBOSE, TIMING OFF)
SELECT * FROM orders WHERE user_id = 123 AND create_time >= '2025-01-01';

加上BUFFERS可以看到每个节点占用的缓存命中/未命中情况；VERBOSE会输出更详细的输出列信息；TIMING OFF在数据量大时可以避免逐节点计时带来的额外开销。

解读时关注几个指标：

• actual time：节点实际执行耗时，不是严格累计值；
• actual rows：实际返回行数；
• loops：节点被循环执行的次数；
• buffers：shared hit表示命中共享缓冲区，shared read表示发生了物理读，如果read数量很大说明预热不足。

曾经有个索引明明存在但查询没走索引的案例，EXPLAIN ANALYZE后我一眼就看到估算行数是1，实际输出300万行。走到统计信息检查那一步，发现这张表已经很久没有ANALYZE，直方图完全失真。执行ANALYZE后，计划才恢复正常。

5.2 一条慢SQL的生产排查路径

生产环境中，一条SQL变慢，先不要急着改SQL。按下面这个顺序排查，往往能少走弯路：

1. 从日志或监控里拿到慢SQL文本、执行时间、报错信息；
2. 查看pg_stat_activity，确认是否存在锁等待或长时间运行的事务；
3. 用慢SQL执行EXPLAIN ANALYZE，观察执行计划是否合理；
4. 查看执行计划中每个节点的估算行数和实际行数，判断统计信息是否陈旧；
5. 检查表的数据膨胀情况和最近一次ANALYZE/VACUUM时间；
6. 确认shared_buffers、work_mem等参数是否与机器配置匹配；
7. 如果以上都正常，再检查SQL本身的结构、索引使用情况。

这里单独展开第5步。有人会在数据量没变的情况下，遇到查询越来越慢的问题，此时十有八九是表膨胀。判断膨胀程度可以用pgstattuple扩展，或者看pg_stat_user_tables里n_dead_tup和n_live_tup的比例。如果死元组数量占live元组的比例超过一定范围，就该考虑VACUUM或PG_REPACK。

5.3 PostgreSQL慢SQL治理相关的常见排查表

下面这张表是我做排查时参考比较多的，也分享出来给大家。

这张表并不能覆盖所有问题，但能覆盖七成常见生产事故。每一条后面再配合具体的监控指标，就已经能解决大多数场景了。

5.4 关于连接池和预处理计划的一个经验之谈

很多团队的慢SQL不是单条执行慢，而是高并发下整体性能差。这里有一个经常被低估的点：连接池中的内存开销。PostgreSQL每个连接都是一个独立的进程，都会有自己的本地内存区，比如排序和哈希操作都需要分配work_mem。系统默认连接数如果开得很高，要特别注意work_mem和连接数相乘后的总内存占用。假设work_mem=64MB，连接数200，一些操作就可能让单机内存达到几十GB级别。

另一个被忽略的点是ORM生成的SQL通常比较“脏”。比如某些框架会把所有查询字段都列出来，甚至对不需要的字段加函数包装，导致索引失效。遇到线上慢SQL，我通常把ORM生成的SQL拿出来手动执行，再用EXPLAIN ANALYZE观察计划。如果手动执行性能很好，说明问题出在ORM生成的语句结构上，这时候往往需要改写查询或者关闭ORM里的某些自动包装功能。

预处理计划方面，建议对访问频繁、参数分布较为均匀的查询使用PREPARE。对于参数分布极其不均匀的场景，反而要小心generic plan带来的性能陷阱。

6. 几个容易被忽略的执行细节

6.1 LIMIT、OFFSET 和游标的工作方式不太一样

LIMIT不会提前终止整棵执行计划树。例如：

sql复制SELECT * FROM big_table ORDER BY id LIMIT 10;

如果走的是Sort排序节点，优化器可能采用Top-N堆排序，只保留前10个最大值，避免全量排序；如果索引天然有序，就直接取前10条。但如果你写的是OFFSET 1000000，LIMIT 10，数据库仍然要跳过前面100万行才能拿到第1000001行，这个过程不会因为OFFSET很大而变快。优化分页查询时，业界常用的“游标分页”比“OFFSET分页”快得多，本质上就是利用了索引有序扫描天然能定位到某一临界值。

在抓取大批量数据时，游标和单条SELECT的执行方式也有差异。游标允许客户端分批获取结果，服务端执行到“取第一批”时，可能只物化部分结果；但如果是普通的SELECT，执行器会尽可能算完再把结果发给客户端。两者对内存的影响也不一样，所以导出大批量数据时建议使用游标分批读取，避免客户端一次性接收太多数据导致内存溢出。

6.2 函数的稳定性标记会影响执行策略

PostgreSQL里的函数可以分为VOLATILE、STABLE、IMMUTABLE三种稳定性级别。优化器会依据这个标记决定能否做表达式预处理、能否在索引扫描时使用函数结果、能否把函数调用提到循环外。

如果一个函数被错误标记为IMMUTABLE，而它内部又依赖了会变化的数据，优化器会放心大胆地“缓存”函数结果，从而产生错误结果。反之，如果函数被标记为VOLATILE，有时会阻止一些优化，比如索引条件无法把函数调用转换成常数。

实际项目中，自定义函数如果查询中不需要每次重新执行，可以标记为STABLE；如果函数逻辑完全取决于常量输入，可以标记为IMMUTABLE。但一定不要为了优化而谎报稳定性，尤其是函数内部访问了表数据时。我在代码评审里经常强调这一点，因为这类问题隐藏得极深，且很难通过普通测试发现。

6.3 从执行过程里反推“我的SQL为什么慢”

最后从执行过程的整体视角做个小小的“反推练习”。

一条SQL变慢时，你可以做一个简单的二分法：到底是慢在分析阶段、计划阶段、执行阶段，还是数据传输阶段？

• 如果是执行计划生成本身耗时高，多见于多表连接复杂、检查约束很多、继承表很多等场景，通常SQL本身并不慢，但EXPLAIN的“Planning Time”会很高；
• 如果是执行阶段慢，EXPLAIN ANALYZE里能看到某个节点耗时异常；
• 如果是数据传输慢，通常和返回大量结果集有关，可以看客户端是否有网络瓶颈。

需要注意的是，并不存在一个放之四海而皆准的优化套路。先判断瓶颈落在执行链路的哪个环节，再去针对性处理，往往比盲目加索引、改参数更有效。

我自己在做SQL调优时，会把执行过程当成一条“流水线”来看：解析重写如果没问题，就看计划；计划没问题，就看执行；执行没问题，就看扫了多少数据页、走了多少缓存、有没有锁等待。顺着这条链路逐段检查，慢SQL的根因总能定位出来。希望这篇关于PostgreSQL SQL语句执行过程的整理，也能让你少走一些弯路，排查问题时心里更有底。