记录Postgresql 查询慢问题_择维士的博客

相关文章推荐

冷静的课本 · AnalyticDB ...· 3 周前 ·

开心的滑板 · PostgreSQL 慢查询SQL跟踪 - ...· 2 周前 ·

鬼畜的番茄 · 人生第一篇博客_sis的原创人生区征文活动怎 ...· 2 月前 ·

纯真的芒果 · 山东大学2023年高校专项“添翼计划”招生简 ...· 4 月前 ·

激动的警车 · 许可信息公开内容· 1 年前 ·

愉快的哑铃 · 影评｜《独自在海边的夜晚》：深邃的尽头 - 知乎· 1 年前 ·

骑白马的大熊猫 · LEDE(OpenWrt)安装opencla ...· 1 年前 ·

最终发现是一个很普通的sql：

select * from int_twilio_twilionumber where merchant_id = 1234 and active = true and "default"=true
order by date_created limit 1

这个查询竟然发了2-3分钟无法回复。

1. 查看表大小 800MB：，表记录大概4000条。

SELECT pg_size_pretty( pg_total_relation_size('int_twilio_twilionumber') );

2. 查看当时pg stat：

PostgreSQL: Documentation: 12: 27.2. The Statistics Collector

select * from pg_stat_activity where query like 'select * from int_twilio_twilionumber%' order by backend_start desc limit 20

发现请求状态如下：

发现阻塞在IO操作上，怀疑是vacuum有问题。

文档有说：


       wait_event_type


       text

The type of event for which the backend is waiting, if any; otherwise NULL. Possible values are:

LWLock : The backend is waiting for a lightweight lock. Each such lock protects a particular data structure in shared memory. wait_event will contain a name identifying the purpose of the lightweight lock. (Some locks have specific names; others are part of a group of locks each with a similar purpose.)
Lock : The backend is waiting for a heavyweight lock. Heavyweight locks, also known as lock manager locks or simply locks, primarily protect SQL-visible objects such as tables. However, they are also used to ensure mutual exclusion for certain internal operations such as relation extension. wait_event will identify the type of lock awaited.
BufferPin : The server process is waiting to access to a data buffer during a period when no other process can be examining that buffer. Buffer pin waits can be protracted if another process holds an open cursor which last read data from the buffer in question.
Activity : The server process is idle. This is used by system processes waiting for activity in their main processing loop. wait_event will identify the specific wait point.
Extension : The server process is waiting for activity in an extension module. This category is useful for modules to track custom waiting points.
Client : The server process is waiting for some activity on a socket from user applications, and that the server expects something to happen that is independent from its internal processes. wait_event will identify the specific wait point.
IPC : The server process is waiting for some activity from another process in the server. wait_event will identify the specific wait point.
Timeout : The server process is waiting for a timeout to expire. wait_event will identify the specific wait point.
IO : The server process is waiting for a IO to complete. wait_event will identify the specific wait point.

3. 用同样的数据创建一个新表发现查询很快。

CREATE TABLE test_twilio_twilionumber AS
SELECT
    int_twilio_twilionumber

4. 执行vacuum操作，问题解决。该操作很慢！而且会锁表。

vacuum (VERBOSE, analyze) int_twilio_twilionumber
vacuum full int_twilio_twilionumber

PostgreSQL: Documentation: 9.5: VACUUM

1. 如果pg某个查询很慢， 排除sql语句性能问题 后，可以查看表： pg_stat_activity.

2. 如果怀疑是磁盘错误可以使用vacuum full拷贝数据。

文章目录 postgresql 数据库 查询慢的原因之一（死元祖太多） postgresql 表清理收缩前言一、元组是什么？二、 postgresql 的解决方法自动清理自动清理相关参数2. 查询当前正在进行自动清理的表及相关信息3、查询自动清理的历史统计信息手动清理数据表收缩总结在使用 postgresql 数据库 时，有时往往会发现有时候查询速度非常慢，以往十几秒就查询出来的，结果需要20多秒才行，看了看发现没有锁， 1、Create Index Directly 2、Change Conditions to Use Index 3、尽量避免在where子句中对字段进行运算，导致查询规划器放弃使用index 4、尽量避免在where子句中对字段类型进行强制转换，导致查询规划器放弃使用index 5、少用outer join，减少不必要的sub-query层级数【在不影响得到正确结果的前提下】 6、坚决避免select * 和 redundant columns【多余字段】 7、Index on Expressions 8、Partial Indexes 9、Decompose DDL【分解DDL】 10、Comprehensive optimization【综合优化】 11、索引的创建 12、查找需要删除的索引 13、查找重复的索引 14、查找需要维护的索引，并自定创建索引维护 SQL 15、一个index size影响query plan的例子 PostgreSQL 是一款强大的关系型 数据库 ，但在实际使用过程中，许多用户经常会遇到慢 SQL 的问题。这些问题不仅会降低 数据库 性能，还会直接影响业务流程和用户体验。因此，本文将会深入分析 PostgreSQL 慢 SQL 的原因和优化方案，帮助用户更好地利用这个优秀的 数据库 系统。无论你是初学者还是专业开发者，本文都将为你提供实用的技巧和方法，让你的 PostgreSQL 数据库 始终保持高效快速。 --查出所有表（包含索引）并排序 SELECT table_schema || '.' || table_name AS table_full_name, pg_size_pretty(pg_total_relation_size('"' || tab... 包括,连接池+ 查询缓存+不知道真假的储存过程+ 慢查询记录使用源码使用了E2EE支持库(模块部分思路借鉴了E2EE) 最后..个人觉得..数据量不大的情况下.my sql 比较快...但是.数据量大了.感觉pg sql 比较快..(也可能是因为我不太会 数据库 的原因造成的) 引用的模块源码已经打包了... 这里有绿色版 数据库 http://www.hao sql .com/ (不是广告..我也不确定安不安全..毕竟不是我自己写的,不放心可以官方网站下载),官网下载地址: https://www. postgresql .org/download/windows/ 没有别的可以说了.. 1.UUID概述数据类型uuid存储由RFC 4122、ISO/IEC 9834-8:2005以及相关标准定义的通用唯一标识符（UUID）（某些系统将这种数据类型引用为全局唯一标识符GUID）。这种标识符是一个128位的量，它由一个精心选择的算法产生，该算法能保证在已知空间中任何其他使用相同算法的人能够产生同一个标识符的可能性非常非常小。因此，对于分布式系统，这些标识符相比序列生成器而言提供了一... 目录前言优化过程 数据库 版本总体思路分区键近期优化 SQL 的次数越来越多了，优化的思路可以从 SQL 结构、执行计划、统计信息、执行计划缓存、索引合理性（数据离散度、联合索引等）、程序的 数据库 连接池参数、 数据库 自身参数、 数据库 部署架构等方面看。这次优化涉及了 PostgreSQL 的分区表，和单表不同，分区表有一些特性，导致它和普通表有一些区别，例如 数据库 版本（影响分区表特性）、分区类型（Hash分区、range分区、List分区等）。本次优化的都是Hash分区的，亿级别的基础数据，根据Hash分区