如何通过EXPLAIN ANALYZE结果查看磁盘读写量以判断是否减少数据库颠簸
2026-6-30
从EXPLAIN ANALYZE Buffers看磁盘读写与数据库颠簸优化
一、提取磁盘读写数据量
PostgreSQL中EXPLAIN ANALYZE的Buffers统计单位是8KB的页面，要转换成字节需乘以8192（8×1024）。从你的输出中统计总磁盘读写：
总磁盘读取
- 执行阶段：
shared read=4464047 - 规划阶段：
shared read=9 - 总读取页面数：
4464047 + 9 = 4464056 - 总读取字节数：
4464056 × 8192 ≈ 36.6GB
总磁盘写入
- 执行阶段：
shared written=155 - 规划阶段：
shared written=3 - 总写入页面数：
155 + 3 = 158 - 总写入字节数：
158 × 8192 ≈ 1.28MB
二、当前查询的颠簸原因
你的Update语句对table_a的4个分区执行了全表顺序扫描（Seq Scan），每个分区都扫描了近3000万行数据，最终仅过滤出1行。这种无索引的全表扫描会持续占用大量磁盘IO，是导致数据库颠簸（磁盘频繁读写、系统资源紧张）的主要原因。
三、调整查询可有效减少颠簸
最直接的优化方案是给table_a所有分区的id字段创建B-tree索引（UUID类型适配B-tree索引的等值查询）。创建索引后，查询计划会从全表扫描转为索引扫描（Index Scan），直接定位目标行，彻底避免全表扫描带来的海量磁盘IO。
四、判断调整有效性的核心指标
- 磁盘IO指标：
Buffers中的shared read页面数大幅下降，shared hit占比提升（更多数据从内存缓冲区读取，减少磁盘访问）；written页面数也会因无需扫描大量数据而减少。 - 执行时间：
actual time总耗时显著降低（当前执行时间超100秒，优化后可降至毫秒级）。 - 扫描行数：
Rows Removed by Filter从数百万级骤降为0或极少，执行计划从Seq Scan变为Index Scan/Index Only Scan。 - 系统资源：数据库服务器的磁盘IO使用率、CPU占用率明显下降，消除因持续磁盘IO导致的系统颠簸。
内容的提问来源于stack exchange，提问作者TreeWater
相关产品推荐
相关产品推荐
