PostgreSQL 18的EXPLAIN新字段Index Searches实战解析-代码聚汇网

PostgreSQL 18的EXPLAIN新字段Index Searches实战解析

幸运小姐·2026-09-04·阅读 23 GEO检测（免费）

PostgreSQL 18Index SearchesEXPLAIN

|难度：普通|阅读约 43 分钟

今年年初我在升级测试环境的时候，把一套跑了三年的 PostgreSQL 17 慢查询巡检脚本原样搬到新版本实例上，结果同事跑过来问我：“这个 Index Searches 是从哪冒出来的？为什么一行索引扫描下面多了一个以前没见过的数字？”

我一开始也以为是某个插件或者 auto_explain 配置出的新输出，后来翻了 PostgreSQL 18 开发版的 EXPLAIN 变更记录才确认：这确实是优化器给索引类计划节点新增的统计维度。看完之后我最大的感受是，过去我们太习惯把“索引扫描”当做一个不可拆分的黑盒动作了，而 PostgreSQL 18 想通过 EXPLAIN 告诉你的，恰恰是这个动作里“搜索”到底发生了多少次。这篇文章我把自己的实测过程、理解逻辑和几个翻车场景整理出来，希望能帮 DBA 和做查询优化的人少走一点弯路。

1. 从一次慢查询会诊说起：为什么需要区分“扫描次数”和“搜索次数”

先说个真实场景。那套系统里有一张订单表，大概两亿行，主键是 order_id，业务上经常按 customer_id + status 查最近订单。我在 PostgreSQL 17 上跑了这样一条查询：

sql复制EXPLAIN (ANALYZE, BUFFERS)
SELECT order_id, amount
FROM orders
WHERE customer_id = 10086
  AND status = 'PAID'
ORDER BY created_at DESC
LIMIT 50;

当时计划长这样：

text复制Limit  (cost=0.43..163.94 rows=50 width=32)
  ->  Index Scan Backward using idx_orders_customer_status on orders
      (cost=0.43..163.94 rows=51 width=32)
      Index Cond: (customer_id = 10086)
      Filter: (status = 'PAID'::text)
      Rows Removed by Filter: 53142

如果只看这个输出，你会以为 PostgreSQL 只对索引做了一次“扫描”，扫出来五万多行，再逐行过滤掉不符合 status 的行。但实际上去看 idx_orders_customer_status 这个复合索引，它的设计应该是 (customer_id, status, created_at desc)，为什么计划里还在用 Filter 过滤 status？

这是 PostgreSQL 一项非常常见但容易误导人的行为：如果优化器认为某个条件的选择率很低，它可能会选择只使用复合索引的前缀列做索引条件，剩下的列放在表行或索引元组上过滤。这种“扫一遍再过滤”的动作，在真实执行时并不仅仅是扫描，它会反复进入索引页做定位、跳过、回退，只是传统的 EXPLAIN 不会把每一次“进入索引定位到一段连续区间的动作”单独计数。于是你只能看到 rows、loops、Buffers，却看不到真实发生了多少次检索操作。

PostgreSQL 18 里新增的 Index Searches 就是冲着这个盲区来的。它不是简单的 loops，也不是 rows，而是把一个索引节点的执行过程拆成了“一次计划循环中，实际发起了多少次索引搜索”。

这个字段对两类人特别有用：一类是需要判断“为什么索引没用满”的优化工程师，另一类是写索引推荐工具的人。以前我们只能通过 Buffers 和 Rows Removed by Filter 猜，现在可以直接看到该索引节点内部发生了多少次定位与检索。对 DBA 来说，这相当于多了一个“显微镜”。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. EXPLAIN 中的 Index Searches 到底是什么：位置、字段含义和我的观察方式

我用的 PostgreSQL 18 是 2025 年初的开发版快照，通过源码编译安装，开了 --enable-debug。在 EXPLAIN (ANALYZE, BUFFERS) 输出里，带有索引访问方法的计划节点下方会多出一行：

text复制Index Searches: 327

它的含义，按照我自己的观察可以这样理解：Index Searches 表示该计划节点在执行阶段进入索引搜索例程的次数。注意，它不等于外层 loops，也不等于实际返回的 rows。

举个例子。嵌套循环连接里常见的计划形态是这样的：

text复制Nested Loop  (cost=...)
  ->  Seq Scan on customers c
  ->  Index Scan using idx_orders_customer on orders o
        Index Cond: (customer_id = c.id)
        Index Searches: 1

这里的 Index Searches: 1 表示每次进入这个内层计划节点，只需要执行一次索引查询。但如果某个内层节点在一次循环里要对多个不同条件发起索引检索，比如索引条件来自两个不同参数组合，或者优化器为了处理 OR 条件而拆成了多次检索，Index Searches 就会大于当前节点的 loops。

为了把字段位置讲清楚，我建议在 18 上跑 EXPLAIN (ANALYZE, FORMAT TEXT) 时重点看这类结构：

text复制Index Scan using idx_orders_customer_status on orders o
  (cost=0.43..163.94 rows=51 width=32)
  (actual time=0.014..0.019 rows=3 loops=1)
  Index Cond: (customer_id = 10086)
  Filter: (status = 'PAID'::text)
  Rows Removed by Filter: 53142
  Index Searches: 5

注意不同构建版本可能把 Index Searches 放在 Rows Removed by Filter 之前或之后，字段位置不是重点，重点是别把它当成 Rows Removed by Filter 的别名。为了减少歧义，我自己通常会把输出改成 FORMAT JSON：

json复制{
  "Plan": {
    "Node Type": "Index Scan",
    "Index Name": "idx_orders_customer_status",
    "Actual Rows": 3,
    "Actual Loops": 1,
    "Index Searches": 5,
    "Index Cond": "(customer_id = 10086)",
    "Filter": "(status = 'PAID'::text)"
  }
}

读 JSON 格式时字段名很清晰，也方便写脚本批量统计。这是我强烈建议的一个实操细节。

读这个字段，要和 rows、loops 一起看。下面是我整理的一张快速判断表：

关系	往往说明
Index Searches ≈ loops	每次循环一次常规检索，基本正常
Index Searches > loops	单次循环内发生了多次索引定位，要关注条件拆分
Index Searches >> rows	大量搜索没有产生有效行，多为过滤或回表浪费
Index Searches = rows 且很大	类似逐行“点查”，可能是被外部参数驱动
Index Searches 小于 loops	少见，可能命中了缓存或某些分区裁剪后的短路逻辑

如果你看到 Index Searches 数值几千但返回行数是 0，那就要怀疑是不是索引条件里有大批量的值被用完就丢掉了。这个场景在 IN 列表特别长、又走了嵌套循环参数化路径时很常见。

3. 搜索次数是怎么从计划器传到执行器的：索引探针计数逻辑

传统上，PostgreSQL 的 EXPLAIN 很少告诉你“一条索引扫描为什么贵”。成本模型里，索引扫描的成本由启动成本、每次扫描成本、每次元组处理成本组成，但是你把 EXPLAIN 打开看，默认只会输出最终的 cost、rows、width。如果你只做性能分析，很难把 cost 映射到磁盘上的实际动作。

PostgreSQL 18 的 Index Searches 设计思路我认为是在执行器层面做“索引搜索调用”的计数。计划器在生成路径时，会估算这个节点可能需要启动多少次索引查找；执行器真正执行后，再把实际次数反馈给 EXPLAIN ANALYZE。这个设计很像我们在数“一个人去图书馆查了多少次书”，而不是“他从书架上取走了几本”。如果一个人反复去图书馆，每次只查一个书名，最后借了 3 本书，但他可能跑了 20 次图书馆——Index Searches 记录的是这 20 次，而不是 3 次。

执行器对索引搜索的调用路径一般是：ExecIndexScan 首先根据 IndexCond 调用索引的 amrescan 或 amgettuple，建立一次新的搜索位置，之后通过 amgettuple 不断取下一个满足条件的索引条目。很多老的 EXPLAIN 使用者以为 loops=1 就是只搜索了一次，其实并非如此。一个位图堆扫描节点扫描 10 个数据页，计划节点 loops 可能只是 1，但底层为了定位每个堆页对应的索引项，已经发生了多次独立的索引遍历。

让我用一个具体的计划片段说明：

text复制Bitmap Heap Scan on orders o
  Recheck Cond: ((customer_id = 10086) OR (amount > 100000))
  ...
  ->  BitmapOr
        ->  Bitmap Index Scan on idx_orders_customer
        ->  Bitmap Index Scan on idx_orders_amount

传统输出里，你只知道走了两个 Bitmap Index Scan，它们各自扫描了多少个索引块，你不清楚这两个扫描合并后，堆表需要重新检查多少次条件。而加入 Index Searches 之后，如果其中一个 Bitmap Index Scan 因为筛选后得到的行太多，执行器不得不多次回索引重新精确匹配，就能看到它的 Index Searches 明显偏高，这其实比 Recheck Cond 更早地暴露了问题。

为什么这个字段以前不好统计？因为 PostgreSQL 的索引访问方法接口非常抽象。不同的索引类型，比如 B-tree、GiST、GIN，它们的“搜索”概念并不一致。B-tree 的搜索很好理解，就是从根节点出发定位叶子页；GIN 的搜索则可能涉及多个词位、多个 posting list。要做到统一计数，必须把统计点放在 IndexScan 节点的公共流程里，而不是每一种索引访问方法内部。这也是为什么该特性在语义上会有不少争论：究竟是把“一次 amrescan”算一次搜索，还是把“每调用一次 amgettuple 进入新的叶子页分支”算一次搜索？

从我的实测数据看，PostgreSQL 18 开发版的实现更接近前者：主要统计 amrescan 和重新初始化扫描状态带来的“重新定位次数”。也就是说，它更贴近“一次独立检索请求”这个概念。比如 Bitmap Index Scan 本身通常只 rescan 一次，那么它的 Index Searches 就不会像索引扫描那样随结果行数上涨。这就是为什么看到某个 Index Scan 下 Index Searches 特别大时，我第一反应会去看它是不是位于嵌套循环内部，且索引条件与外层参数相关。

有朋友会问，这个功能能通过 EXPLAIN（不带 ANALYZE）看到吗？至少在 18 的当前构建里，不带 ANALYZE 时只显示计划器估算的成本，不显示执行计数。真正能读到 Index Searches: N 的格式是 EXPLAIN (ANALYZE)。如果你在跑 EXPLAIN 时没加 ANALYZE，看不到这个字段很正常，并不代表功能无效。

如果你希望它默认被 auto_explain 记录到日志里，可以在 auto_explain 配置下开启 auto_explain_log_analyze，并检查 auto_explain_log_format 设置。日志中的计划同样会保留该字段。

4. 拿到 Index Searches 后怎么用：三类典型计划的判读路线图

新增一个字段不难，难的是知道怎么从它里面读出优化结论。下面我结合最近实际压测和问题排查，总结了三类典型场景。

4.1 场景一：嵌套循环内层索引节点上的“搜索次数异常增长”

嵌套循环是最直观能看到 Index Searches 价值的场景。比如这样的查询：

sql复制EXPLAIN (ANALYZE, BUFFERS)
SELECT c.customer_name, o.order_id
FROM customers c
JOIN orders o ON o.customer_id = c.customer_id
WHERE c.signup_date >= '2024-01-01'
LIMIT 1000;

如果优化器选择对 customers 做顺序扫描，然后对于每个客户都去 orders 的 (customer_id) 索引上精确匹配，那么计划形态就是：

text复制Nested Loop
  ->  Seq Scan on customers c
  ->  Index Scan using idx_orders_customer on orders o
        Index Cond: (o.customer_id = c.customer_id)

假设外层 Seq Scan 过滤出 5 万名客户，那么内层 Index Scan 节点的 loops 就会是 5 万左右。很多人在做性能排查时，看到 loops=50000 就会认为内层索引被重复执行了 5 万次，从而判断“嵌套循环是罪魁祸首”。但真实性能瓶颈不一定在循环次数上，而在于每个循环里的搜索是否有重复。

如果这 5 万次循环里，有许多客户的 customer_id 是重复的，或者由于 work_mem 不足导致缓存失效，那么同一个 customer_id 在同一个连接生命周期里被反复搜索了很多次。Index Searches 在这里会大于 loops，差距越大，说明重复搜索浪费越明显。

我在另一个订单系统里测试过一个极端例子：外层过滤出的 5 万客户里，头部几个大客户的 customer_id 极其集中，内层索引扫描实际返回了 3000 万行，但因为 LIMIT 存在，执行器提前结束了。当时计划中 Index Searches 到达了 7 万多次，仅用一个内层 loops=50000 看不出来，因为每轮循环并不是干净的“一次搜索”，其中有一批循环重新触发了多次定位。

遇到这种情况，可以依次尝试三条优化路径：

把嵌套循环改成哈希连接。如果 LIMIT 不强制需要有序输出，哈希连接能彻底避免反复搜索。
增大 work_mem，看是否因为 Memoize 节点缓存空间不足导致重复搜索。Memoize 会把相同参数跑过的结果缓存起来，如果缓存被挤出，Index Searches 会成倍上涨。
使用 enable_memoize=off 做对照实验，确认重复搜索的来源。注意在 18 里如果你同时打开 EXPLAIN (ANALYZE, SETTINGS)，计划中会显示 Memoize 的命中和未命中统计，配合 Index Searches 阅读会更清晰。

4.2 场景二：Bitmap Index Scan 和 lossy 页导致的伪“高搜索”

PostgreSQL 的位图扫描机制是：先用索引生成一个位图，再按位图顺序去读堆表。位图本身有两种存储形态：精确位图（exact）和有损位图（lossy）。work_mem 太小的时候，位图会把一部分页面标记为 lossy，表示“这一页里可能有不止一个满足条件的行”。之后读取堆表时，它需要重新检查原有条件。

在 18 之前，判断 lossy 页是否过多时，我会看 Bitmap Heap Scan 节点下的 Recheck Cond 和 Rows Removed by Index Recheck。如果 Rows Removed by Index Recheck 很大，说明位图把所有行都指了过来，但很多达不到条件。

加入 Index Searches 后，我还需要关注 Bitmap Index Scan 节点本身是否因为 bitset 溢出而做了多次归并检索。简单说：位图扫描如果内存足够，一个 Bitmap Index Scan 基本是一次搜索之后把结果丢进位图；但如果 work_mem 太紧张，它可能分批把索引项取出、构建位图、再进入下一批，整个过程会表现为多个索引搜索动作。

我这里做过一个对照实验：

sql复制SET work_mem = '64kB';
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM events
WHERE event_time BETWEEN '2025-01-01' AND '2025-01-07'
  AND event_type = 'CLICK';

计划显示 Bitmap Index Scan 下有很高的 Index Searches，同时 Bitmap Heap Scan 的输出里出现 Rows Removed by Index Recheck。把 work_mem 调整到 8MB 后，同样的 SQL，Index Searches 大幅下降，查询总耗时也从 800ms 降到 120ms。这个案例说明一个问题：Index Searches 不只是为嵌套循环场景服务的，它同样能反映位图扫描内部的内存压力。

所以，每当你看到 Bitmap Index Scan 节点的 Index Searches 很高，不要马上怀疑索引失效，先查一下当前 work_mem，再看 heap scan 的 Rows Removed by Index Recheck。这两个指标配合起来，要比单纯判断“顺序扫描还是索引扫描”准确得多。

4.3 场景三：分区表剪枝后，为什么搜索次数比分区数还多

分区表是另一个很容易被误导的地方。我们有一套按月分区的日志表，查询语句总会带上月份条件。EXPLAIN 输出中典型的情况是只扫描一个分区。但某些跨分区条件会带来麻烦：

sql复制SELECT *
FROM logs
WHERE log_date >= '2025-06-01'
  AND log_date < '2025-07-01'
  AND app_id IN (1001, 1002, 1003)
  AND user_id = 7777;

假设你有月份分区，也有 app_id + user_id 的本地索引。优化器可能选择对所有三个 app_id 分别执行一次索引搜索，然后把结果合并。传统输出里，你只能看到分区上的 Append 节点，里面可能是三个 Index Scan，但无法直接看出每个 Index Scan 的搜索请求数量。

有了 Index Searches 后，我遇到一个很有趣的现象：某个分区的分区键本身能把数据限定到一个月，按理说一个索引搜索就够了，但 Index Searches 显示为 2 到 3 次。用 auto_explain 抓到完整计划后仔细看，发现是因为参数化路径和代码路径里，索引搜索要为 IN 列表中的每个值重新定位一次 B-tree 起始位置。IN 列表越长，Index Searches 的数量可能越大。

这可能不完全是坏事，因为对 B-tree 来说，IN (1001, 1002, 1003) 转换成三次搜索是符合执行器模型的。但如果你原本期望做一个 Append 或 BitmapOr 来合并多个索引结果，却看到三个独立 Index Scan 被串行执行，并且每个都重复做着相同的索引搜索，那就要考虑调整查询写法或增加组合索引，避免执行器反复打开同一颗索引树。

4.4 一个快速对照表：看到高 Index Searches 后我依次检查什么

场景特征	第一步检查	第二步优化
Nested Loop 内层 Index Searches 高	缓存是否足够，是否缺 Memoize	加复合索引或改哈希连接
Bitmap Index Scan Index Searches 高	work_mem 是否过小	调 work_mem，避免 lossy 位图
IN 列表触发的多次 Index Searches	是否存在可合并的复合索引	改写为归并条件或建更好的索引
唯一约束检查时 Index Searches 偏高	是否重复检查同一个键	考虑延迟约束或批量写入
索引扫描但 rows 很少	是否触发了很多次短搜索	检查外层参数分布，使用 JOIN 消除

5. 调优实战：当 Index Searches 明显“偏大”时的处理顺序

前面讲了不少理论，这里给一个可以直接复制到工单上的排查流程。遇到一条查询变慢，EXPLAIN (ANALYZE, BUFFERS) 里发现某个索引节点的 Index Searches 偏大，我通常会按下面的顺序操作，而不是一上来就改索引。

5.1 第一步：先数清楚“一个循环”里到底发生了几次搜索

先看这个节点所在的位置。如果上层是 Nested Loop，把 Index Searches 除以 loops，得到“每循环平均搜索次数”。如果这个值是 1，说明计划层面没有浪费，问题多半在外层循环数量太多；如果大于 2，就要继续看 Index Cond 和 Filter 条件了。

比如说一个节点：

text复制Index Scan using idx_orders_customer_status on orders o
  (actual time=0.030..0.050 rows=2 loops=1000)
  Index Searches: 3000

每循环搜索次数 = 3，说明它不是每次外层行只搜一次，而是平均搜了三次。这种情况我会把 Index Cond 展开看，是不是条件里有 customer_id = ANY($1) 这种数组参数。如果上层参数本身带有多个值，执行器通常会对每个参数值执行一次独立的索引搜索，直到找到边界。此时真正的优化方向是把数组改成一个 LATERAL 连接带 unnest，或者让优化器转成 Merge Join。

5.2 第二步：结合排序操作判断搜索是否有“重复定位”

在没有 ANALYZE 时，Index Searches 如果为 3，可能是单次循环里执行器为了获得排序好的数据，反复重置了扫描位置。最典型的就是索引扫描加了 ORDER BY 和 LIMIT。我在一个分页查询场景里见过：

sql复制SELECT *
FROM orders
WHERE customer_id = 10086
ORDER BY created_at DESC
LIMIT 20;

如果索引是 (customer_id, created_at DESC)，执行器可以直接走索引返回前 20 行。但如果索引写反了，或者优化器认为行数不够多，它会走 Index Scan + Sort。传统计划里会显示 Sort Method: quicksort 和 Sort Space Used，不会直接给出一个“索引定位次数”。在 18 的测试中，这类查询如果索引条件定位准确，Index Searches 会非常低，低到接近 1；如果发生了需要不断往前翻页再退回的情况，Index Searches 会高得离谱。

分页深翻页是另一个典型。OFFSET 100000 LIMIT 20 看起来像同一棵索引扫描了 100020 行，但实际上执行器可能为滑动窗口反复发起了多次位置调整。Index Searches 能够帮我们量化这种“游标式回卷”的开销。对深分页优化来说，最经典的手段仍然是改成 keyset pagination：

sql复制WHERE customer_id = 10086
  AND (created_at, order_id) < ('2025-01-01', 100000)
ORDER BY created_at DESC, order_id DESC
LIMIT 20;

改造后，执行器的搜索边界更清晰，Index Searches 的数值也会明显回落。这不是因为 OFFSET 语法被禁止，而是因为索引搜索不再需要每次跳跃一大段行数。

5.3 第三步：检查是不是索引 Recheck 被算成了多次搜索

还有一种我踩过的坑：表的行版本信息和索引元组不一致。比如在 HOT 更新频繁的表上，索引扫描拿到一条索引元组后，发现表里对应行的 ctid 已经变了，需要回表看新版本。如果索引中记录的位置不对，执行器会尝试按新位置重新搜索。这种情况下，Index Searches 会比实际逻辑上的“一次条件查询”高，还会伴随明显的 Buffers: shared read 增大。

要确认这一点，可以看 Index Scan 节点下有没有 Heap Fetches 字段。Heap Fetches 表示从索引元组回表获取堆元组的次数。如果一个原本满足条件的索引元组，在执行器获取堆版本时发现该行对当前快照不可见，执行器会跳过它并继续搜索。这个“跳过并继续搜索”的动作，会推高 Index Searches。更麻烦的是，Heap Fetches 本身并不代表错误，它只是正常可见性判断的一部分。只有当 Index Searches 和 Heap Fetches 同时很高，且 rows 很低时，才说明表上的死行比例可能偏大，后续事务的可见性判断占了太多执行时间。

这种情况下，单纯加索引没用。我遇到过最夸张的一次，同样的查询在夜间 vacuum 后耗时为原来的五分之一，就是因为死行版本大量减少，Index Searches 从几万掉到几百。这里一定要提醒同事：看到 Index Searches 高，别一上来就 REINDEX。先 VACUUM 一下再看，很可能问题已经解决。

5.4 第四步：用开关做二分实验

PostgreSQL 提供了一组 enable_* 参数，用来控制优化器是否启用某种计划。利用它们可以快速定位“正是这个动作导致搜索次数暴增”。比如：

sql复制SET enable_memoize = off;
EXPLAIN (ANALYZE, BUFFERS) ...;

SET enable_memoize = on;
EXPLAIN (ANALYZE, BUFFERS) ...;

对比两个计划中同一节点的 Index Searches。如果关闭 Memoize 后搜索次数大幅上升，说明缓存失效导致重复搜索是主因，解法是提高缓存命中率而不是强行改写 SQL。同样可以用 enable_hashjoin、enable_nestloop 做计划形状的对照。这个实验方法在 PostgreSQL 18 之前也有，但以前没有 Index Searches 这个量化指标，很多 DBA 只能靠感觉判断，现在可以明确看到数字变化。

这类实验做完后，记得把 SET 的状态还原，或者直接开一个新会话，避免影响其他会话的执行计划。

6. 我的踩坑笔记和后续扩展

这个新字段虽然好用，但它并不是银弹，下面记录几个我自己踩过的坑。

第一，不要把它当成一个权威的性能基线。它在 PostgreSQL 18 开发版里还比较年轻，不同索引访问方法的计数口径可能不一致。比如 B-tree 索引的搜索次数和 GIN 索引的搜索次数之间，不能直接比大小。GIN 的底层实现里，一次用户层 amrescan 可能对应多个内部 posting list 的扫描，所以数字会更大。如果拿 GIN 索引的 Index Searches 和 B-tree 索引的做横向对比，意义不大。

第二，读 Index Searches 一定要带上 Buffers。数据库的性能问题绕不开 I/O 和缓存。一个 Index Searches = 10000 的节点，如果所有页面都已经缓存在 shared buffer 里，可能只需要几毫秒；另一个 Index Searches = 100 的节点，如果每个搜索都打到了磁盘，可能更慢。这个字段负责告诉你“请求发生了多少次”，Buffers 负责告诉你“这些请求有多少代价”，两者缺一不可。

第三，要特别留意 EXPLAIN 输出在并行计划里的位置。并行查询中，每个 worker 进程都会执行自己的局部计划，因此 Index Searches 是汇总值还是单个 worker 的值，目前在不同构建版本上显示口径可能不同。我在一个使用 Parallel Seq Scan 的表上测试时，看到主计划节点下 Workers Launched: 2，而 Index Searches 显示的是所有 worker 的汇总。如果你在统计脚本里想按每个 worker 平均，需要确认一下自己用的版本上该字段是否包含 worker 汇总。

第四，如果你在用 EXPLAIN (ANALYZE, SUMMARY) 这种带耗时总结的模式，注意系统里如果启用了 track_io_timing，输出里会多出 I/O Timings。多字段并存时不要只看 Index Searches。比如同样一个索引节点，Index Searches 下降可能只是因为 planner 选了另一个索引，而真正问题是那个新索引虽然搜索次数少，但每次搜索要读取更大的索引页加表行，总耗时反而上升。我在做一次索引类型选型时，就碰到过 Index Searches 减少了 60%，但整体耗时反而增加的情况。所以判断优化效果，始终以总执行时间和总缓冲页数为准，Index Searches 只能作为定位方向的辅助。

第五，让开发同学理解这个字段有一个不错的类比：搜索次数相当于“你去数据库查了多少次资料”，扫描行数相当于“你翻看了多少本书的内容”。一次慢查询可能只返回几行，但为了找到这几行，数据库可能反复在索引里做定位，搜索次数非常高。如果把优化目标停留在“减少返回行数”上，方向可能从一开始就是错的。

最后说一个我自己会持续关注的点：如果 PostgreSQL 18 把这个计数做到 pg_stat 视图层面，而不是只在 EXPLAIN 里显示，那会是一个更强的优化入口。未来我们可以按索引汇总每小时的总搜索次数，用它来识别哪些索引实际承担了大量点查压力，进而判断是否可以把某些索引合并。目前如果你需要做类似的长期统计，可以先通过 auto_explain 把包含 Index Searches 的有问题计划捞到日志，再用正则表达式做汇总。我自己写的巡检脚本，每隔十分钟抓一次慢查询日志，遇到 Index Searches 超过阈值的节点就自动提取索引名、sqlid 和数值，跑了大概一周，还真找出了几个此前从未怀疑过的“高频小查询”。这些查询的单次执行成本都很低，但因为触发频率极高，合计占掉的 I/O 不小。

所以，这个字段的最大价值不在于让你一眼看出“这条 SQL 要不要加索引”，而在于帮你建立起对索引执行过程的量化感觉。等你看多了 Index Searches 与 loops、rows、Buffers 的组合，你会慢慢形成一种条件反射：看到一个计划，脑海里就能推演出执行器真实往返于内存与磁盘之间的流程。这种感觉是任何静态成本估算都替代不了的。

如果你也在用 PostgreSQL 18 的开发版，建议从今天开始，把 EXPLAIN (ANALYZE, BUFFERS) 换成 EXPLAIN (ANALYZE, BUFFERS, SETTINGS, FORMAT JSON)，把计划保存下来，对比几个不同写法下的 Index Searches 数值，很快你就能找到自己系统里那些隐藏的重复搜索点。这个字段目前还比较新，等正式版发布后，我预计会有越来越多的 DBA 把它写进巡检标准里。希望这篇总结能帮你少踩几个我已经踩过的坑。