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

今年年初我在升级测试环境的时候，把一套跑了三年的 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 来说，这相当于多了一个“显微镜”。

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 数值几千但返回行数是 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 看不出来，因为每轮循环并不是干净的“一次搜索”，其中有一批循环重新触发了多次定位。

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

1. 把嵌套循环改成哈希连接。如果 LIMIT 不强制需要有序输出，哈希连接能彻底避免反复搜索。
2. 增大 work_mem，看是否因为 Memoize 节点缓存空间不足导致重复搜索。Memoize 会把相同参数跑过的结果缓存起来，如果缓存被挤出，Index Searches 会成倍上涨。
3. 使用 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 后我依次检查什么

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 把它写进巡检标准里。希望这篇总结能帮你少踩几个我已经踩过的坑。