各位，我是老张。今天从一次实战出发，往下拆一层。

上周二早上八点四十，监控大屏红了。订单查询接口的P99从9毫秒飙到1.2秒，值班同学甩过来一句“索引失效了”。我看了眼表结构，`orders`上明明挂着`idx_status_create_time`，字段顺序也对。既然索引在，为什么不走？“失效”两个字解释不了任何东西，优化器不会无缘无故犯傻，它每一步都在算账。

今天就把这笔账拆开。先给结论：现代数据库的优化器是成本估算器，不是规则机。它不走索引，要么是它算错了，要么是它没错，是你错怪了它。绝大多数“索引失效”，根子都在统计信息和代价模型这两个地方。

| 关键点 | 说明 |
| --- | --- |
| 优化器类型 | CBO，按代价选路，不按规则 |
| 选路依据 | 统计信息 + 代价模型，两者任一失真就选错 |
| 最常翻车点 | 统计信息过期、选择性估算偏差、回表代价被低估 |
| 隐形杀手 | 索引列被函数包裹，索引直接作废 |

## 优化器不是“有索引就用”

老一辈数据库用过规则式优化器，RBO。规则写死了：有索引就走索引，等值优先于范围。简单，但蠢。数据分布一变，规则就成了枷锁。现在主流都换成了CBO，成本式优化器。它的逻辑只有三步。第一步，给每个过滤条件估算选择率，也就是大概能筛出多少行。第二步，给每条候选执行路径算一个代价分数。第三步，挑分数最低的那条走。

关键在于，优化器手里没有真实数据，它只有统计信息。统计信息是抽样来的，是一张数据分布的“剖面图”。剖面图画歪了，决策必然跟着歪。所以问题从来不是“索引好不好用”，而是“优化器以为它好用不好用”。

## 第一步，看统计信息准不准

统计信息由`ANALYZE`收集。它会从表中随机抽取约`300 × default_statistics_target`行作为样本，目标值100时就是三万行。表大的时候，这三万行只是一小撮样本。优化器靠样本去推整体分布，样本里没抓到的热点值，它就当不存在。

排查第一步，直接查系统表。看优化器眼里这张表长什么样：

```sql
-- 表级概览：行数、页数
SELECT reltuples, relpages FROM pg_class WHERE relname = 'orders';

-- 列级分布：去重值、高频值、相关性
SELECT attname, n_distinct, most_common_vals, correlation
FROM pg_stats WHERE tablename = 'orders';
```

这里有两个字段要盯死。`most_common_vals`是高频值列表，等值查询的选择率基本靠它。`correlation`是物理顺序和逻辑顺序的相关度，取值-1到1。它接近1，说明索引扫描回表时基本是顺序读；接近0，就是满地随机跳。我们那次事故，统计信息还停在三个月前，高频值里压根没有新上线的`PAID`状态。优化器以为`status='PAID'`能命中九成行，一算，全表扫更便宜。

## 第二步，看代价模型算得对不对

代价模型是一组权重参数的加权求和。核心就这几个：

```
顺序读一页:   seq_page_cost   = 1.0
随机读一页:   random_page_cost = 4.0
处理一行:     cpu_tuple_cost  = 0.01
```

顺序扫描的代价，约等于页数乘`seq_page_cost`，再加行数乘`cpu_tuple_cost`。索引扫描的代价，是索引树几页随机读，加上按估算行数回表取数据的随机读。一条SQL的代价，就是这些项加起来，单位是抽象的“页”。

这里藏着大坑。默认`random_page_cost=4`，是机械硬盘时代定的。机械盘随机寻道确实比顺序读慢四倍。但现在满机房的NVMe SSD，随机读和顺序读的差距被抹平了。参数还按机械盘配，优化器就会系统性高估索引扫描的代价，本该走索引的场景，它偏拉去全表扫。SSD上的经验值，`random_page_cost`可以往`1.1`附近调。但这个数取决于具体硬件和负载，我不敢说放之四海皆准，得压测验证。

看执行计划别光看选的哪条路，要看它算的账：

```sql
EXPLAIN (ANALYZE, BUFFERS, VERBOSE)
SELECT * FROM orders
WHERE status = 'PAID' AND create_time > '2026-09-01';
```

`EXPLAIN`不加`ANALYZE`只给估算值，加了才真跑一遍、给实际值。两个值一对比，问题就露出来了。

## 一次现场：估算和实际差了两个数量级

我们那次，优化器选了全表扫描。为什么？它估算`status='PAID'`命中约38万行，占全表九成。既然要读九成，那还不如一把顺序扫到底，省得反复回表。

但真实情况是，`PAID`只占0.3%，一张表里就几千行。真相很简单：统计信息三个月没刷新，新状态没进去，估算彻底失真。跑一次`ANALYZE orders`，`most_common_vals`补上了`PAID`，估算行数从38万掉到4000多，优化器立刻改走索引。P99从1.2秒落回9毫秒。

| 指标 | ANALYZE前 | ANALYZE后 |
| --- | --- | --- |
| 估算命中行数 | 386,420 | 4,180 |
| 实际命中行数 | 4,231 | 4,231 |
| 优化器选择 | 全表扫描 | 索引扫描 |
| 接口P99 | 1.2s | 9ms |

看估算命中行数那一行。ANALYZE前估了38万，实际只有4千出头，差了近百倍。优化器再聪明也没用，它不是在骗你，它是在按你给的错误信息认真干活。

## 索引不走，多半是这几种原因

统计信息只是其一。我整理过一份现场排查清单，按出现频率排：

| 原因 | 典型写法 | 排查手段 |
| --- | --- | --- |
| 统计信息过期 | 大表长期没ANALYZE | 查pg_stats，比对reltuples |
| 索引列被函数包裹 | `WHERE date(create_time)=...` | 改写或建表达式索引 |
| 隐式类型转换 | 列是varchar，传int参数 | 显式对齐参数类型 |
| 选择性太低 | 条件命中行数占比过高 | 看估算行数，本就该全表扫 |
| 回表代价被高估 | SSD仍用random_page_cost=4 | 调参后重测 |
| 前导通配 | `LIKE '%关键字'` | 改后缀匹配或全文索引 |

重点说隐式类型转换，它最阴。字段是`varchar`，Java传进来的参数是`int`，数据库得给字段套一层类型转换函数才能比较。一旦套上函数，索引列就变成了“表达式”，B+Tree没法用。这种坑不看执行计划根本发现不了。

## 压测数据：选择性决定走法

索引不是万能钥匙，走不走它取决于命中多少行。我在16核64G、NVMe的机器上，拿一张500万行的订单表压过一轮。

| 命中行占比 | 全表扫描P99 | 索引+回表P99 | 优化器选择 |
| --- | --- | --- | --- |
| 0.1% | 340ms | 3ms | 索引 |
| 1% | 340ms | 9ms | 索引 |
| 30% | 340ms | 345ms | 全表（拐点） |
| 60% | 340ms | 360ms | 全表 |
| 100% | 340ms | 590ms | 全表 |

看这张表的形状。命中占比低时，索引扫描是碾压性的优势。占比爬到三成左右，两条线交汇。再往上，优化器选全表扫反而是对的，因为回表变成大量随机读，成本超过顺序扫。所以有些“索引不走”，是优化器英明，是你错怪了它。判断标准很简单：先看估算行数占比，过了三成全表扫往往更划算。不过这个拐点取决于`random_page_cost`和`seq_page_cost`的比值，以及表的correlation，不同配置下位置会变。

## 决策框架

我把这套流程压成四步，现场直接套用。

第一步，跑`EXPLAIN ANALYZE`，拿估算行数和实际行数对比。差一个数量级以内，说明统计信息可信，问题在别处；差得多，直接`ANALYZE`。

第二步，`ANALYZE`后还不走，查`pg_stats`的`most_common_vals`和`correlation`。偏斜数据要靠调高`default_statistics_target`来抓准。

第三步，估算准了还不走，怀疑代价参数。SSD上把`random_page_cost`往下调，重测执行计划。

第四步，以上都正常还不走，问题在SQL本身。函数包裹、隐式转换、前导通配，逐个对。必要时建表达式索引或覆盖索引。

## 踩过的坑

第一个坑，我调参调反了方向。以为`random_page_cost`越高越倾向索引，其实越高越倾向全表扫，因为随机读被算得更贵了。这个方向我一开始记反了，白折腾半天。

第二个坑，只跑`EXPLAIN`不跑`ANALYZE`。`EXPLAIN`给的是估算，本身就可能是错的。拿错的估算去判断优化器蠢不蠢，等于用错题本找答案。

第三个坑，也是最脏的一次。分区表上，父表的全局统计信息长期没更新，分区裁剪本身是对的，但父表的代价估算离谱。查询走对了分区，计划却选错了走法。分区表的`ANALYZE`得连父表一起管，光刷子表没用。

## 结语

索引不走，不是玄学，是一道算错的数学题。优化器算账的三样输入，统计信息、选择率、代价参数，任何一样失真，结论就偏。搞懂它怎么算，排查就从“猜”变成了“验”。

我写这篇，不是让你去背参数。是想说，遇到索引不走，别急着加hint硬掰。先把`EXPLAIN ANALYZE`跑出来，看它估算多少、实际多少，答案基本就在那两个数字里。

各位遇到过最离谱的索引不走是什么场景？是函数包了列，还是统计信息馊了？评论区说说，一起对计划。

我是底层玩家老张。咱不聊概念，只聊源码和压测跑出来的东西。


上周二早上八点四十，监控大屏红了。订单查询接口的P99从9毫秒飙到1.2秒，值班同学甩过来一句“索引失效了”。我看了眼表结构，orders上明明挂着idx_status_create_time，字段顺序也对。既然索引在，为什么不走？“失效”两个字解释不了任何东西，优化器不会无缘无故犯傻，它每一步都在算账。

索引为什么不走：优化器成本估算与执行计划

从一次订单查询P99飙到1.2秒的事故出发，拆解CBO查询优化器的统计信息、选择率估算与代价模型，讲清“索引失效”背后优化器到底在算什么

数据库

后端

职业发展

数据库索引失效常因统计信息过期或代价模型失真，优化器基于CBO估算而非规则判断。排查需对比EXPLAIN ANALYZE的估算与实际行数，检查pg_stats高频值及random_page_cost参数。SSD建议调至1.1，命中超30%时全表扫描更优。

代码解释

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

索引为什么不走：优化器成本估算与执行计划-腾讯云开发者社区-腾讯云

索引为什么不走：优化器成本估算与执行计划

索引为什么不走：优化器成本估算与执行计划

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐