尧图网站建设 尧图网络
  • 首页
  • 关于我们
  • 服务项目
  • 案例展示
  • 建站流程
  • 资讯中心
  • 联系我们
首页/资讯中心/详情

别让 PG 背锅:一次真实慢查询的 7 步排查记录

别让 PG 背锅:一次真实慢查询的 7 步排查记录
📅 发布时间:2026/6/19 4:40:51

问题定位与解决方案

慢查询问题定位慢查询主要出现在以下SQL语句:

SELECT o.id, o.amount, u.nick FROM orders o JOIN users u ON u.id = o.user_id WHERE o.status = 'PAID' AND o.pay_time >= '2025-12-17 00:00:00' ORDER BY o.id DESC LIMIT 20;

执行时间为38秒,问题根源在于索引未有效过滤数据,导致全表扫描。

执行计划分析通过EXPLAIN (ANALYZE, BUFFERS)分析执行计划:

Limit (cost=0.56..2923.45 rows=20 width=48) (actual time=38042.213..38042.215 rows=20 loops=1) -> Nested Loop (cost=0.56..2342342.11 rows=16043 width=48) -> Index Scan Backward using orders_pkey on orders o (cost=0.56..823234.22 rows=16043 width=32) Filter: ((status = 'PAID'::order_status) AND (pay_time >= '2025-12-17 00:00:00'::timestamp)) Rows Removed by Filter: 12345678 -> Index Scan using users_pkey on users u (cost=0.56..8.77 rows=1 width=24) Index Cond: (id = o.user_id) Buffers: shared hit=52346 read=1234567 I/O Timings: read=30452.123

关键问题在于Rows Removed by Filter: 12345678,说明索引未有效过滤数据。

索引优化方案现有索引:

\d orders Indexes: "orders_pkey" PRIMARY KEY, btree (id) "idx_orders_status" btree (status) "idx_orders_paytime" btree (pay_time)

优化方案是创建复合索引:

CREATE INDEX CONCURRENTLY idx_orders_status_paytime_id ON orders (status, pay_time DESC, id DESC);

优化后执行计划:

Limit (cost=0.56..12.34 rows=20 width=48) (actual time=0.381..0.389 rows=20 loops=1) -> Index Scan using idx_orders_status_paytime_id on orders o ... Index Cond: ((status = 'PAID'::order_status) AND (pay_time >= '2025-12-17 00:00:00'::timestamp)) Buffers: shared hit=64

执行时间从38秒降至0.38毫秒。

参数优化调整以下参数以进一步提升性能:

ALTER SYSTEM SET random_page_cost = 1.1; ALTER SYSTEM SET work_mem = '32MB'; SELECT pg_reload_conf();

验证与效果优化后SQL平均执行时间从28秒降至0.4毫秒,QPS回升至1.9万。

常用诊断SQL

-- 当前活跃慢查询 SELECT pid, now()-xact_start, left(query,120) FROM pg_stat_activity WHERE state='active' AND now()-xact_start > interval '3 s'; -- 表+索引大小 SELECT relname, pg_size_pretty(pg_total_relation_size(relid)) FROM pg_catalog.pg_statio_user_tables ORDER BY pg_total_relation_size(relid) DESC LIMIT 10; -- 未使用的索引 SELECT schemaname, relname, indexrelname, idx_scan FROM pg_stat_user_indexes WHERE idx_scan=0;

相关新闻

  • 小模型逆袭!一文读懂模型蒸馏:为何小参数也能媲美大模型?
  • Open-AutoGLM比价自动化实战,20年技术老兵首次公开核心算法逻辑
  • 为什么顶尖程序员都在研究Open-AutoGLM自动下单?真相曝光!

最新新闻

  • 3个理由选择D3keyHelper:暗黑3玩家的终极智能自动化助手
  • 解锁Citra模拟器:从基础渲染到专业级画质调优
  • lidR架构解析与林业LiDAR数据处理高级应用
  • Vue3 为什么选择 Proxy?看完这篇彻底搞懂 JavaScript 代理模式
  • 云原生技术17-从Nginx到Envoy:为什么大厂都在迁移?xDS协议 + WASM扩展:Envoy高级玩法实战
  • HugeJsonViewer:打破GB级JSON文件查看的性能瓶颈

日新闻

  • 5分钟掌握Python进化算法:Geatpy高性能优化工具完全指南
  • Microchip 24AA044 EEPROM选型与应用全指南:从参数解析到实战编程
  • 华为的鸿蒙到底有多牛?为什么称作遥遥领先?

周新闻

  • 3步解锁iOS设备:applera1n激活锁绕过完全指南
  • 39 2026 人工智能证书终极盘点,普通人选 AI 证书可以从这些方向入手
  • Redis 暴露公网有多危险?从端口检查到补救步骤

月新闻

  • 【总结】入门篇:50句话让你记住架构核心概念
  • WeChatMsg技术方案解析:实现Mac微信数据自主管理的完整解决方案
  • WeChatMsg:革新性微信数据备份方案,打造你的专属数字记忆库

关于尧图

  • 公司简介
  • 团队介绍
  • 企业文化
  • 荣誉资质

服务项目

  • 定制开发
  • 电商建站
  • UI 设计
  • 运维服务

快速链接

  • 案例展示
  • 建站流程
  • 常见问题
  • 资讯中心

联系方式

  • 📍北京市朝阳区互联网产业园 A 座 10 层
  • 📞400-888-8888
  • ✉️contact@rkmt.cn
  • 🕐周一至周日 9:00-21:00

© 2024 北京尧图网络科技有限公司 版权所有 | 京 ICP 备 XXXXXXXX 号