EXPLAIN · XB 现场笔记

查询变慢时同时检查计划与等待

Mon, 31 Jan 2028 00:00:00 +0000

一条过去很快的查询，可以在数据、统计和访问计划都没有变化时变慢。另一个事务可能持有它需要的锁，存储缓存可能比上次更冷，应用也可能在语句进入 PostgreSQL 之前就开始等待。重新检查计划很有用，但它应当放在完整的耗时比较中：先区分时间是花在执行工作上，还是花在等待获得执行机会。不能从“现在更慢”直接推导出“数据与统计一定都变了”。

保留可比较的基线

记录语句形状、有代表性的参数值、返回行数、相关会话设置，以及应用是否使用预备语句。不同参数可能命中完全不同规模的数据。手工使用常量的查询，不一定复现预备语句采用的通用计划；不同角色或搜索路径，也可能改变实际对象与权限。因此，拿一条看起来相似的语句作为对照，并不保证比较条件相同。

尽量在变慢正在发生时观察活动。pg_stat_activity 可以显示一个状态为运行中的查询正在等待锁；运行中并不等于持续消耗处理器。pg_blocking_pids 列出当前阻塞这个后端的会话。查看其他角色活动需要适当权限，因此字段不可见不等于没有工作发生。交互观察最好使用新的自动提交查询，而不是在同一个长事务中不断读取已经缓存的监控快照。

坏掉的样子

不加判断就运行 ANALYZE，相当于把每次变慢都当成统计陈旧。它可能增加维护工作，却完全没有解除真正的阻塞。一张只有一行的表，即使新增索引，也不能释放其他事务持有的行锁。准确的行数估计和很小的顺序扫描，可以与很长的应用等待同时存在；这两种观察并不矛盾。

EXPLAIN ANALYZE 会真正执行语句，写入也不例外，而且测量本身同样可能被阻塞。从生产环境复制一条大范围更新，不是无害的检查。应先看等待情况和锁的拥有者，再选择安全夹具或副作用已经明确的语句来测量。看到某个进程编号出现在阻塞列表中，也不能立即终止不熟悉的事务，因为它可能正在完成另一个有效业务操作。

没有锁等待的计划样本，也不等于端到端延迟。EXPLAIN ANALYZE 不会像普通查询那样把结果行发送给客户端；未指定 SERIALIZE 时，还不包含输出转换。TIMING OFF 减少逐节点计时开销，但仍保留总执行时间。大量结果传输、应用解码和连接池排队，需要在计划之外单独观察，不能从这里的执行时间中直接读出。

快速验证

打开三个新的 psql 会话，分别记作甲、乙、丙，连接同一个可丢弃的 PostgreSQL 18 数据库并使用相同角色，保留通常的自动提交行为。名为 query_recheck_demo 的模式必须尚不存在。务必区分会话：把所有代码块顺序粘贴到同一个连接，无法证明事务之间的阻塞。

在甲中建立夹具，然后开启事务，修改唯一一条记录但暂不提交。

\set ON_ERROR_STOP on
CREATE SCHEMA query_recheck_demo;
CREATE TABLE query_recheck_demo.items (id integer PRIMARY KEY,value integer);
INSERT INTO query_recheck_demo.items VALUES (1,0);
ANALYZE query_recheck_demo.items;

BEGIN;
UPDATE query_recheck_demo.items SET value=10 WHERE id=1;
SELECT pg_backend_pid() AS blocker_pid;

在乙中发起带执行测量的更新。它会等待甲结束事务，或者等到六十秒的语句超时。

SET application_name='xbcatm_recheck_waiter';
SET statement_timeout='60s';
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
UPDATE query_recheck_demo.items SET value=value+1 WHERE id=1;

乙仍在等待且尚未超时时，在丙中执行观察查询。实验专用应用名称用于定位乙，不需要展示整条查询文本。

SELECT pid,state,wait_event_type,wait_event,pg_blocking_pids(pid) AS blockers
FROM pg_stat_activity WHERE application_name='xbcatm_recheck_waiter';

回到甲，撤销尚未提交的变更并释放锁，然后收集乙执行完毕后的计划。

ROLLBACK;

确认乙已经成功结束后，在丙中检查最终数据并清理夹具。

SELECT value FROM query_recheck_demo.items WHERE id=1;
DROP SCHEMA query_recheck_demo CASCADE;

原文记录的 PostgreSQL 18.6 观察未在本轮重新执行，其中乙的状态为运行中，等待类型是 Lock，具体等待事件是 transactionid，阻塞列表包含甲的进程编号。具体事件可能随争用过程变化，核心证据是乙确实被甲阻塞。甲回滚后，乙把原本的零加成一，最后查询返回一，清理语句移除了整个实验模式。

乙的扫描估计并读取一行；最上层 Update 节点实际返回零行，是因为没有 RETURNING 子句，不表示没有修改数据。总体执行时间包含人为制造的等待，长短取决于甲何时释放事务，不能把这个数字当作扫描一行的固有成本。如果乙先超时，就先回滚甲，并用丙的最后一个代码块清理夹具后再重新开始。取消的更新并不等同于成功加一，不能沿用成功情况的结果解释。

顺着观察到的原因继续

如果证据指向锁等待，先调查事务持有时间和归属，再考虑访问路径。如果实际处理的行太多，则比较过滤选择率与当前统计。如果排序或哈希操作发生溢写，就检查内存和临时读写。最后还要把数据库执行时间与应用请求延迟比较，识别连接建立、连接池排队或客户端处理的部分。只有新计划能够解释测得的回归，并保持所需结果，计划变化才构成有效改进。

来源

PostgreSQL 18：监控数据库活动，活动会话与等待观察，已核验 2026-10-15。
PostgreSQL 18：使用 EXPLAIN，行数、循环次数与计划解读，已核验 2026-10-15。
PostgreSQL 信息函数，通过 pg_blocking_pids 识别阻塞会话，已核验 2026-10-15。

EXPLAIN ANALYZE 把查询真的跑一遍

Thu, 16 Dec 2027 00:00:00 +0000

EXPLAIN 展示 PostgreSQL 的执行计划，EXPLAIN ANALYZE 还会真正执行语句并测量工作量。最有用的比较，是同一个节点的估计行数与实际行数。两者都不能单独当成结论：估计来自模型，实测则只描述特定数据、缓存、并发和插桩条件下的一次执行。不能把前者称为谎言，也不能把后者当成脱离环境的永恒事实。

先比较同一种量

计划中的 cost 是相对成本单位，不是毫秒。两个成本值分别描述启动成本与完成成本，带 LIMIT 的查询可能更重视尽早得到前几行，因此选择不同计划。actual time 才使用毫秒。即使成本和耗时恰好都打印成一百，也不能把它们直接相减或求比例；它们本来就不表示同一件事。

一个节点被重复执行时，actual rows 和节点耗时是每次循环的平均值，需要结合 loops 理解总工作量。但不能把所有节点耗时简单相加，因为父节点已经包含子节点的工作，重复相加会重复计算。并行执行时更不能用这种方式猜总延迟。先沿树看输入输出、循环次数、过滤条件和行数流向，再决定哪个位置值得调查。

BUFFERS 区分 shared、local 和临时块活动。shared hit 表示 PostgreSQL 在共享缓冲区里找到了块；shared read 只表示需要读入，操作系统仍可能从页缓存满足它，不能直接断言每次都访问了物理磁盘。临时表使用本地缓冲区，排序或哈希溢出则可能读写临时文件。父节点计数包含子节点，逐行把所有计数加起来同样会夸大 I/O。

找到有意义的估计偏差

某个选择性条件估计只返回十行，实际却返回一万行，通常值得先调查，再考虑重写其上方的连接。统计信息陈旧、分布倾斜、列间相关、参数值变化或选择性模型能力不足，都可能造成偏差。ANALYZE 可以刷新统计信息，却不能保证每个估计精确，也不会自动修好所有慢计划。先看真实数据和缺失的信息，再决定是否调整统计目标或增加扩展统计。

行数估计准确也不能证明查询高效。缺少访问路径、昂贵表达式、排序溢出、锁等待和并发争用仍可能存在。反过来，小表或需要返回大量行的查询采用顺序扫描可能正合适，不应把“没用索引”一律判为错误。分析时应保留应用实际使用的参数和查询形状，避免用一个稀有值的漂亮计划替代整个生产分布。

坏掉的样子

最危险的误解，是把 ANALYZE 当成只读预演。UPDATE 会改变行，触发器会执行，锁会被获取，SELECT 也可能调用带副作用的函数。事务末尾执行 ROLLBACK 可以恢复事务性表变化，却不能一般性撤销序列前进或外部系统副作用。对语句影响范围不确定时，应使用可丢弃的数据集，不能靠“最后会回滚”就放心在生产运行。

另一个误判来自测量本身。第一次执行会加热缓存，频繁读取时钟的成本也可能占据廉价节点的大部分时间。TIMING OFF 仍保留实际行数和整条语句的总耗时，同时避免逐节点计时。EXPLAIN 不会把普通结果集完整发送给应用，所以它不能测出传送整个响应的网络耗时。重复执行、代表性负载和应用延迟各自回答不同问题，应结合解释而不是只挑最小的毫秒值。

快速验证

用 psql 连接一个可丢弃的 PostgreSQL 18 数据库，把代码保存为 explain.sql，再运行 psql -X -v ON_ERROR_STOP=1 -f explain.sql；连接参数应明确指向实验库。这里创建的表和序列都是临时对象，最后回滚会清除它们，不需要借用已有 orders 表，也不会假定生产中存在某个字段。

\set ON_ERROR_STOP on
BEGIN;
SET LOCAL statement_timeout = '5s';
CREATE TEMP TABLE orders (id integer, status text);
INSERT INTO orders SELECT g, CASE WHEN g <= 100 THEN 'paid' ELSE 'new' END
FROM generate_series(1, 10000) AS g;
ANALYZE orders;
EXPLAIN (COSTS ON) SELECT * FROM orders WHERE status = 'paid';
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT * FROM orders WHERE status = 'paid';
CREATE TEMP SEQUENCE measured_calls;
SAVEPOINT before_measurement;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
UPDATE orders SET id = id + 10000 WHERE id <= 3;
EXPLAIN (ANALYZE, TIMING OFF) SELECT nextval('measured_calls');
ROLLBACK TO SAVEPOINT before_measurement;
SELECT count(*) AS updated_rows_after_rollback FROM orders WHERE id > 10000;
SELECT nextval('measured_calls') AS sequence_after_rollback;
DO $$ BEGIN
 IF (SELECT count(*) FROM orders WHERE status = 'paid') <> 100 THEN
 RAISE EXCEPTION 'unexpected selected row count';
 END IF;
 IF EXISTS (SELECT FROM orders WHERE id > 10000) THEN
 RAISE EXCEPTION 'UPDATE was not rolled back';
 END IF;
 IF (SELECT last_value FROM measured_calls) <> 2 THEN
 RAISE EXCEPTION 'sequence advance unexpectedly rolled back';
 END IF;
END $$;
ROLLBACK;

夹具恰好包含一百条 paid 订单。实际执行的 SELECT 应显示一百行通过过滤、九千九百行被过滤。UPDATE 下方的扫描节点处理三行，但没有 RETURNING 时顶层节点返回零行；这个零不代表没有更新。回滚到保存点后，更新后的行数回到零，但下一次序列值是二，因为被测 SELECT 已经消耗了第一个值。代码为这些结果提供断言，而不是仅打印一个看似合理的计划。

在 PostgreSQL 18.6 上这些断言通过。具体计划、缓冲区计数、耗时和打印格式可以变化，稳定预期是行数、回滚效果与序列前进。五秒 statement timeout 限制本实验中单条语句的执行时间，但不会把任意生产写操作变成安全检查。临时对象和受控数据是这个实验可复现的前提，不能移除后仍声称风险相同。

来源

PostgreSQL EXPLAIN，真实执行的副作用和测量选项，已核验 2026-09-10。
PostgreSQL 使用 EXPLAIN，成本、循环次数与缓冲区解释，已核验 2026-09-10。
PostgreSQL 规划器统计信息，估计与统计模型的边界，已核验 2026-09-10。
PostgreSQL 序列函数，不随回滚撤销的序列前进，已核验 2026-09-10。

EXPLAIN 让你看清 Postgres 会怎么做

Thu, 08 Jul 2027 00:00:00 +0000

EXPLAIN 打印规划器准备采用的执行计划与代价；EXPLAIN ANALYZE 则真的跑一遍语句，把估算变成测到的行数与时间。它们回答的是两个不同问题：规划器认为应该怎样做，以及数据库实际怎样做。排障时先看前者理解意图，再用后者测量现实，别把 cost 当成秒数，也别在生产库上无准备地执行一条会写数据的 ANALYZE。

计划提供需要核对的估计与观测，而不是单凭行数差异就能完成的诊断。循环次数和提前停止也会制造表面差距；估计准确时，查询仍可能受到锁等待、溢写或大量必要工作的影响。它告诉你读了哪些表、用了什么索引、预计经过多少行，以及每个节点把多少工作交给下一个节点。把计划保存进工单，和请求参数、统计信息更新时间、数据库版本一起记录，几周后的回归才有可比基线。只贴一句“慢”没有证据；保存计划能帮助定位值得检验的假设，但不能自动解释所有请求延迟。

自上而下读形状

文本计划先打印父节点，再缩进打印它的子节点。向下读可以理解节点依赖哪些输入，向上看可以理解结果怎样汇合。执行可能按需发生：上层的 LIMIT 得到足够多的行便会停止索取，下层排序却可能需要读完全部输入才能交出第一行。缩进描述依赖关系，并不是所有节点通用的执行时间顺序。

cost 使用规划器的工作量单位，不是毫秒。父节点总成本包含子节点，不能把整棵树的数字直接求和。启动成本表示返回第一行前预计投入多少工作，总成本表示完成节点的估算。实际时间和实际行数在 loops 大于一时按每次执行取平均；判断重复工作要结合循环次数，同时避免把父节点包含的子节点时间再加一次。

阅读时先问三个问题。第一，计划是否走了预期的访问路径，例如选择性很高的条件是否用了索引。第二，估算行数和实际行数是否在同一个数量级，数量级错了通常比单个节点的 cost 更值得处理。第三，数据流在哪里膨胀或等待，宽大的中间结果会把后面的排序、连接和聚合一起拖慢。沿着这三个问题读，计划就从一堆术语变成了可验证的因果链。

追踪工作量与放大点

行数最多只是线索，不能直接证明瓶颈。连续读取的大表扫描可能比随机访问索引更便宜，一个每次很快却反复执行数万次的节点也可能主导延迟。先找估算与实际第一次发生明显偏离的地方，再追踪它怎样影响后续连接、排序与内存。嵌套循环并非天然错误：外表很小、内表有匹配索引时它可能最快；危险的是外表被严重低估后仍反复访问内表。

把计划格式化为 JSON 可以让工具比较节点，手工排障先用普通 EXPLAIN 确认访问路径，再按需执行带 ANALYZE、BUFFERS 的测量。缓冲命中、缓冲读取、临时文件读写能帮助定位数据访问与排序落盘。缓冲读取不等于真实磁盘读取，因为操作系统缓存也可能提供数据；看到 read 就宣布磁盘慢，证据还不够。VERBOSE 会显示更多输出列和别名，适合定位复杂视图。

用 ANALYZE 让行数和代价对齐

EXPLAIN ANALYZE 会真实执行查询，同时给出估算与实际行数、节点耗时和循环次数。两者出入很大，可能来自统计过时、分布倾斜或列间相关性；重新收集统计有时能改善，但不能保证修好所有偏差。写入实验放到隔离数据库，并设置语句超时。事务回滚只能撤销可回滚的数据库改动，不能撤销已经分配的序列值、函数或触发器对外部系统造成的不可回滚副作用。SELECT 也可能调用带副作用的函数，不能只根据语句开头判断安全。

可以按需提高相关列的统计目标，或者建立描述同一张表中相关列的扩展统计，但这些动作也要由测量验证。扩展统计不能修复所有估计，目前也不是跨表连接选择性的通用信息来源；应先确认它改变了真正有问题的估计，再归因于统计改进。索引收益仍要根据整个查询的工作量评估。若同一语句对小租户很快、对大租户很慢，要用应用实际的预备语句路径比较通用计划和定制计划。PostgreSQL 核心并没有通用的 SQL 提示语法，不要凭空加入提示来强行选择节点。每次只改变一个变量，把结果集、计划和延迟并排保存。

坏掉的样子

第一种失败是调错了查询。一个页面发出五条语句，工程师给最熟悉的那一条加索引，用户延迟却没有变化，因为真正耗时的是另一个查询。可以按 pg_stat_statements 的累计执行时间筛选候选，再关联具体慢请求；累计耗时很高也可能只是调用频繁，不能单凭这个排名解释某次请求的尾延迟。应结合调用次数、参数和请求追踪，避免让熟悉程度代替耗时证据。估算行数远小于实际行数时，再沿循环次数和数据流找放大点，而不是先全局禁用某种连接算法。

另一个故障是把 EXPLAIN ANALYZE 当成无副作用的测速命令。有人在主库直接跑大批量更新，结果测试本身锁住业务、写入 WAL，还触发了通知或审计。修法是先复制语句到隔离副本，读查询用 BEGIN 和超时保护，写查询先用普通 EXPLAIN 估算，再用生产级回放数据测量。计划采集也要脱敏参数，避免把客户信息带进日志或工单。

另一种常见失败是参数敏感性被平均值掩盖。某个租户占了大多数数据，其他租户很小，共用的预备语句通用计划却无法同时照顾两种分布。用两个有代表性的参数分别保存计划，再检查统计、查询形状和实际执行路径。每个优化动作都应对应结果不变及资源消耗改善的证据，否则只是换了一段计划文本。

快速验证

在允许写入的临时实验数据库执行下面的事务。数据表属于当前会话，结束时回滚清理，不依赖已有订单或客户表：

BEGIN;
SET LOCAL statement_timeout = '10s';
CREATE TEMP TABLE explain_demo AS
SELECT n AS id, n % 100 AS tenant_id FROM generate_series(1, 20000) AS g(n);
ANALYZE explain_demo;
EXPLAIN (ANALYZE, BUFFERS)
SELECT id FROM explain_demo WHERE tenant_id = 17 ORDER BY id LIMIT 10;
SELECT id FROM explain_demo WHERE tenant_id = 17 ORDER BY id LIMIT 10;
CREATE INDEX explain_demo_lookup ON explain_demo (tenant_id, id);
EXPLAIN (ANALYZE, BUFFERS)
SELECT id FROM explain_demo WHERE tenant_id = 17 ORDER BY id LIMIT 10;
SELECT id FROM explain_demo WHERE tenant_id = 17 ORDER BY id LIMIT 10;
ROLLBACK;

两次普通 SELECT 都应返回从 17 到 917、间隔一百的十个编号。比较两份计划中的扫描类型、排序节点、过滤行数与缓冲访问；第二份通常会利用有序索引。不同版本和环境的精确节点形状与耗时可以不同，不要把某个毫秒数字写成硬性断言。回滚后实验对象消失；迁移到真实业务前，还需用接近生产分布的数据重复测量，并确认其他重要查询没有回退。

来源

PostgreSQL EXPLAIN 文档，EXPLAIN 选项与真实执行的副作用，已核验 2026-10-15。
PostgreSQL 使用 EXPLAIN，说明计划节点、估算行数与 ANALYZE 输出，已核验 2026-10-15。
PostgreSQL 18: Extended statistics，同表列相关性及 ANALYZE 采集，已核验 2026-10-15。
PostgreSQL 18: CREATE STATISTICS，统计种类与表连接选择率估算的限制，已核验 2026-10-15。
PostgreSQL 18: pg_stat_statements，调用次数与累计执行时间，已核验 2026-10-15。

EXPLAIN · XB 现场笔记

查询变慢时同时检查计划与等待

保留可比较的基线

坏掉的样子

快速验证

顺着观察到的原因继续

来源

EXPLAIN ANALYZE 把查询真的跑一遍

先比较同一种量

找到有意义的估计偏差

坏掉的样子

快速验证

来源

EXPLAIN 让你看清 Postgres 会怎么做

自上而下读形状

追踪工作量与放大点

用 ANALYZE 让行数和代价对齐

坏掉的样子

快速验证

延伸阅读

来源