PG 查詢優化：觀宏之道

在線業務數據庫中，慢查詢不僅影響終端用戶體驗，還會浪費系統資源、拉高資源飽和度、導致死鎖和事務衝突，增加數據庫連接壓力，導致主從複製延遲等問題。因此，查詢優化是 DBA 的核心工作內容之一。

在查詢優化這條路上，有兩種不同的方法：

宏觀優化：整體分析工作負載，對其進行剖分下鑽，自上而下地識別並改進其中表現最糟糕的部分。

微觀優化：分析並改進一條特定的查詢，這便需要記錄慢查詢日誌，掌握 EXPLAIN 的玄機，領悟執行計劃的奧妙。

今天我們先來說說前者，宏觀優化有三個主要目標與動機：

減少資源消耗：降低資源飽和的風險，優化 CPU / 內存 / IO，通常以查詢總耗時 / 總 IO 作爲優化目標。

改善用戶體驗：最常見的優化目標，在 OLTP 系統中通常以降低查詢平均響應時間作爲優化目標。

平衡工作負載：確保不同查詢組之間的資源使用 / 性能表現的比例關係得當。

實現這些目標的關鍵在於數據支撐，但是數據從哪裏來？

—— pg_stat_statements！

擴展插件：PGSS

pg_stat_statements，以下簡稱 PGSS ，是踐行觀宏之道的核心工具。

PGSS 出自 PostgreSQL 全球開發組官方之手，以第一方擴展插件的形式，隨數據庫內核本體一併發行，提供了跟蹤 SQL 查詢語句級別指標的方法。

PostgreSQL 生態中有許許多多的擴展，但如果說有哪一個是 “必選” 的，我必定會毫不猶豫的回答：PGSS。這也是在 Pigsty 中，我們寧願 “自作主張”，也要默認啓用並主動加載的兩個擴展之一。（另一個是用於微觀優化的 auto_explain）

PGSS 需要在 shared_preload_library 中顯式指定加載，並在數據庫中通過 CREATE EXTENSION 顯式創建。創建擴展後即可通過視圖 pg_stat_statements 訪問查詢的統計信息。

在 PGSS 中，系統中的每一類查詢（即抽取變量後，執行計劃相同的查詢）都會被分配一個查詢 ID，緊接着是調用次數，執行總耗時，以及各種其他指標，其完整模式定義如下（PG15+）：

PGSS 視圖的 SQL 定義（PG 15 + 版本）

PGSS 也有一些侷限性：首先，正在執行中的查詢語句並不會納入這裏的統計，而需要從 pg_stat_activity 中查看獲取。其次，執行失敗的查詢（例如，因爲 statement_timeout 超時被取消的語句）也不會被計入這裏的統計 —— 這是錯誤分析要解決的問題，而不是查詢優化所關心的目標。

最後，查詢標識符 queryid 的穩定性需要特別注意：當數據庫二進制版本和系統數據目錄完全相同時，同一類查詢會具有相同的 queryid （即在物理複製的主從上，同類查詢的 queryid 默認是相同的），然而對於邏輯複製則不然。但用戶不應當對這一性質抱有過度的依賴與假設。

原始數據

PGSS 視圖中的列可以分爲三類：

描述性的標籤列（Label）：查詢 ID（queryid）、數據庫 ID（dbid）、用戶（userid），一個頂層查詢標記，和標準化的查詢文本（query）。

測量性的指標（Gauge）：與最小、最大、均值標準差有關的八列統計量，以 min，max，mean，stddev 作爲前綴，以 plan_time 與 exec_time 作爲後綴。

累積性的指標（Counter）：除了上面八列與標籤列的其他指標，例如 calls、rows 等，最重要、最有用的指標都在這一類裏。

首先解釋一下 queryid：queryid 是查詢語句被解析後，剝離常量後生成規範化查詢的哈希值，因此可以用來標識同一類查詢。不同的查詢語句可能有着同樣的 queryid （規範化後結構一樣），同樣的查詢語句也可能有着不同的 queryid （例如因爲 search_path 不同，導致實際查詢的表不懂）。

同樣的查詢可能會在不同的數據庫中被不同的用戶所執行。因此在 PGSS 視圖中，queryid，dbid，userid，toplevel 四個標籤列，共同組成了唯一標識一條記錄的 “主鍵”。

對於指標列而言，測量性質的指標（GAUGE） 主要是執行時間與計劃時間相關的八個統計量，然而用戶沒有辦法很好地控制這些統計量的統計範圍，所以實用價值並不大。

真正重要的指標是累積性的指標（Counter），例如：

calls ：此查詢組發生了多少次調用。

total_exec_time + total_plan_time：查詢組累計耗費時間。

rows：查詢組累計返回了多少行。

shared_blks_hit + shared_blks_read：緩衝池累計命中和讀取操作次數。

wal_bytes：此組中的查詢累計生成的 WAL 字節數。

blk_read_time 和 blk_write_time：累計花費在塊讀寫 IO 上的時間

這裏，最有意義的指標是 calls 與 total_exec_time，可以用於計算查詢組的核心指標 QPS （吞吐量）與 RT（延遲 / 響應時間），但其他的指標也很有參考價值。

可視化展現 PGSS 視圖的某個查詢組快照

要解讀累積性指標數據，只有某一個時刻的數據是不夠的。我們需要對比至少兩個時刻的快照，才能得到有意義的結論。

作爲特例，如果您感興趣的範圍正好是從統計週期伊始（通常是啓用此擴展時）至今，那麼確實不需要對比 “兩個快照”。但用戶感興趣的時間粒度通常並不會這麼粗放，而往往是以分鐘、小時、天爲單位。

根據多個 PGSS 查詢組快照計算歷史時序指標

好在類似 Pigsty 監控系統這樣的工具會定期（默認每隔 10s）截取頭部查詢（耗時 Top256）的快照。有了許多不同類型的累積指標 M（etrics）在不同時刻的快照之後，我們就能計算出某個累積性指標的三種重要派生指標：

dM/dt：指標 M 基於時間的微分，即每秒的增量。

dM/dc：指標 M 基於調用次數的微分，即每次調用的平均增量。

%M：指標 M 在整個工作負載中所佔的百分比。

這三類指標正好與宏觀優化的三類目標相對應，對時間的微分 dM/dt 揭示了每秒資源使用量，通常用於減少資源消耗的優化目標。對調用次數的微分 dM/dc 揭示了每次調用的資源使用量，通常用於改善用戶體驗的優化目標。而百分比指標 %M 展示了查詢組在整個工作負載中所佔的百分比，通常用於平衡工作負載的優化目標。

對時間微分

讓我們首先來看第一類指標：對時間的微分。在這裏，我們可以使用的指標 M 包括：calls，total_exec_time，rows，wal_bytes，shared_blks_hit + shared_blks_read，以及 blk_read_time + blk_write_time。其他的指標也有參考意義，但讓我們從最重要的開始。

可視化展現對時間的微分指標 dM/dt

計算這些指標的方式其實很簡單，我們只需要：

• 首先計算兩個快照之間的指標值 M 的差值：M2 - M1

• 然後計算兩個快照之間的時間差值：t2 - t1

• 最終計算 (M2 - M1) / (t2 - t1) 即可

生產環境通常會使用 5s，10s，15s，30s，60s 這樣的數據採樣間隔。對於負載分析通常會使用 1m， 5m，15m 作爲常用的分析窗口大小。

例如，當我們計算 QPS 時，就會分別計算最近 1 分鐘，5 分鐘，15 分鐘的 QPS。窗口越長曲線就越平穩，更能反映長期變化趨勢；但是會隱藏短期波動細節，不利於發現瞬時異常波動，所以不同粒度的指標需要結合來看。

展示特定查詢組 1/5/15 分鐘窗口下的 QPS

如果您使用 Pigsty / Prometheus 來採集監控數據，那麼可以使用 PromQL 簡單地完成這些計算工作。例如，計算所有查詢最近 1 分鐘的 QPS 指標，使用以下語句就可以了： rate(pg_query_calls{}[1m]) 

QPS

當 M 是 calls 時，對時間求導的結果是 QPS，它的單位是每秒查詢數（req/s），這是一個非常基礎的指標。查詢 QPS 屬於吞吐量指標，直接反應了業務施加的負載狀況，如果一個查詢的吞吐量過高（例如，10000+）或者過低（例如，1-），有可能是值得關注的。

QPS：1/5/15 分鐘 µ/CV， ±1/3σ分佈

如果我們把所有查詢組的 QPS 指標累加起來（且沒超過 PGSS 的收集範圍），就會得到所謂的 “全局 QPS”。另一種獲得全局 QPS 的方式是在客戶端打點，在類似 Pgbouncer 的連接池中間件上採集，或者使用 ebpf 探測。但都不如 PGSS 方便。

請注意，QPS 指標並不具備負載意義上的橫向可比性。不同查詢組可能有着同樣的 QPS，而單個查詢的耗時卻天差地別。甚至同一個查詢組在不同時間點上產生的負載水平，也可能因爲執行計劃不同而發生巨大變化。每秒執行時長是一個更好的衡量負載的指標。

每秒執行時長

當 M 是 total_exec_time （+ total_plan_time，可選 ）時，我們就會得到宏觀優化中最重要的指標之一：在查詢組上耗費的的執行時間，有意思的是，這個導數的單位是 秒 / 每秒，所以分子分母相互約掉了，使得它實際上是一個無量綱的指標。

這個指標的涵義是：服務器每秒鐘花費多少秒來處理這個查詢組中的查詢，例如 2 s/s 意味着服務器每秒花費兩秒執行時間在這組查詢上；對於多核 CPU，這當然是有可能的：把兩個 CPU 核的全部時間都拿來就行了。

每秒執行時長：1/5/15 分鐘均值

因此這裏的值也可以理解爲一個百分比：可以超過 100%，在這種視角下，它是一個類似於主機 load1, load5, load15 的指標，揭示了該查詢組產生的負載水平。如果除以 CPU 核數，甚至可以得到歸一化的查詢負載貢獻度指標。

但是我們需要注意的是，執行時間中包括了等待鎖，等待 I/O 的時間。所以確實可能出現這樣的情況：查詢執行時間很長，但卻沒有對 CPU 負載產生影響。所以如果要精細分析慢查詢，我們還要參考等待事件來進一步分析纔行。

每秒行數

當 M 是 rows 時，我們會得到每秒該查詢組返回的行數，單位是行 / 每秒（rows/s）。例如 10000 rows/s 意味着該類查詢每秒向客戶端吐出 1 萬行數據。返回的行需要耗費客戶端的處理資源，當我們需要檢視應用客戶端的數據處理壓力時，這是一個非常有參考意義的指標。

每秒返回的行數：1/5/15 分鐘均值

共享緩衝區訪問帶寬

當 M 是 shared_blks_hit + shared_blks_read 時，我們會得到每秒命中 / 讀取的共享緩衝區塊數，如果將其乘以默認塊大小 8KiB（極少情況下有可能會是其他的大小，例如 32KiB），我們就會得到一類查詢 “訪問” 內存磁盤的帶寬：單位是字節 / 秒。

舉個例子，如果某一類查詢每秒訪問 50 萬次共享緩衝區，摺合 3.8 GiB/s 的內部訪問數據流：那麼這就是一個顯著負載，也許會是一個很好的優化候選項。也許你應該檢查一下這個查詢，看看它是否配得上這些 “資源消耗”。

共享緩衝區訪問帶寬與緩衝區命中率

另一個值得參考的衍生指標是緩衝區命中率：即 hit / (hit + read) ，它可以用於分析性能變化的可能原因 —— 緩存未命中。當然，重複訪問同一個共享緩衝池裏的塊，並不會真的重新讀取，即使真的去讀取，也不一定是讀取磁盤，有可能是讀內存中的 FS Cache。所以這裏只是一個參考值，但它確實是一個非常重要的宏觀查詢優化參考指標。

WAL 日誌量

當 M 是 wal_bytes 時，我們得到了該查詢生成 WAL 的速率，單位是字節 / 每秒（B/s）。這個指標是在 PostgreSQL 13 新引入的，可以用來定量揭示查詢產生的 WAL 大小：寫入的 WAL 越多越快，刷寫磁盤、物理複製 / 邏輯複製、日誌歸檔的壓力就會越大。

一個典型的例子是：BEGIN; DELETE FROM xxx; ROLLBACK; 。這樣的事務刪了很多數據，產生了大量 WAL 卻沒有執行任何有用的工作，通過這個指標可以將其揪出來。

WAL 字節率：1/5/15 分鐘均值

這裏有兩個注意事項：上面我們說過，PGSS 無法跟蹤執行失敗的語句，但這裏事務雖然 ROLLBACK 失敗了，但是語句卻是成功執行了的，所以會被 PGSS 跟蹤記錄。

第二件事是：在 PostgreSQL 中並非僅僅是 INSERT/UPDATE/DELETE 會產生 WAL 日誌，SELECT 操作也有可能產生 WAL 日誌，因爲 SELECT 可能會修改元組上的標記（Hint Bit）讓頁面校驗和出現變化，觸發 WAL 日誌寫入。

甚至存在這種可能，如果讀取負載非常大，它會有較大概率導致 FPI 鏡像生成，產生可觀的 WAL 日誌量。你可以通過進一步檢查 wal_fpi 指標。

共享緩衝區寫髒 / 寫回帶寬

對於 13 以下的版本，共享緩衝區寫髒 / 寫回帶寬指標可以作爲一個近似下位替代，用於分析查詢組的寫入負載特徵。

I/O 耗時

當 M 是 blks_read_time + blks_write_time ，我們會得到查詢組花費在塊 I/O 上的耗時比例，單位是 “秒 / 每秒”，與每秒執行時長指標一樣，它也反映出一樣操作佔用的時間比例。

I/O 耗時對於分析查詢毛刺原因很有幫助

因爲 PostgreSQL 會使用操作系統提供的 FS Cache，所以即使這裏執行了塊讀取 / 寫入，可能在文件系統層面上仍然是發生在內存中的緩衝操作。所以它只能作爲一個參考指標，使用時需要謹慎，需要與主機節點上的磁盤 I/O 監控相互對照。

對時間微分的指標 dM/dt，可以展現出一個數據庫實例 / 集羣內部工作負載的全貌，對於優化資源使用的場景來說尤其有用。但是如果您的優化目標是改善用戶體驗，那麼可能另一組指標 —— 對調用次數的微分 dM/dc，會更有參考意義。

對調用次數微分

上面我們已經計算了六類重要指標對於時間的微分，另一類衍生指標計算方式是對 “調用次數” 進行微分，也就是分母從時間差變成了 QPS。

這類指標重要性相比前者甚至更高，因爲它提供了直接關乎用戶體驗的幾個核心指標，比如最重要的 —— 查詢響應時間（RT，Response Time），或曰 延遲（Latency）。

計算這些指標的方式也很簡單，我們只需要：

• 計算兩個快照之間的指標值 M 的差值：M2 - M1

• 然後計算兩個快照之間的 calls 差值：c2 - c1

• 然後計算 (M2 - M1) / (c2 - c1) 即可

對於 PromQL 實現來說，對於調用次數的微分指標 dM/dc，可以用 “對時間的微分指標 dM/dt” 計算得到。例如要計算 RT，就可以使用 每秒執行時長 / 每秒查詢數 ，兩指標相除即可：

rate(pg_query_exec_time{}[1m]) / rate(pg_query_calls{}[1m])

dM/dt 可以用於計算 dM/dc

調用次數

當 M 是 calls 時，對自己微分沒有任何意義（結果會恆爲 1）。

平均延遲 / 響應時間 / RT

當 M 是 total_exec_time 時，對調用次數求導的結果是 RT，或響應時間 / 延遲。它的單位是秒（s）。RT 直接反映了用戶體驗，是宏觀性能分析中最重要的指標。這個指標的含義是：此查詢組在服務器上的平均查詢響應時間。如果條件允許啓用 pg_stat_statements.track_planning，還可以加上 total_plan_time 一起計算，結果會更精確更具有代表性。

RT：1/5/15 分鐘 µ/CV， ±1/3σ分佈

這裏要特別強調兩種特殊情況：第一：PGSS 不跟蹤失敗 / 執行中的語句；第二：PGSS 的統計數據受（pg_stat_statements.max）參數限制，可能出現部分採樣偏差。儘管有這些侷限性，但想要獲取至關重要的查詢語句組延遲數據，PGSS 毫無疑問是最爲穩妥可靠的來源。正如上面所述，在其他觀測點位也有辦法採集查詢 RT 數據，但會麻煩得多。

你可以在客戶端側打點，採集語句執行時間，通過指標或者日誌上報；你也可以嘗試使用 ebpf 來探測語句 RT，這對基礎設施和工程師要求會比較高。Pgbouncer 和 PostgreSQL （14+） 倒是也提供了 RT 指標，只可惜粒度都是數據庫級別，沒有一個能做到 PGSS 查詢語句組級別的指標收集。

RT：語句級 / 連接池級 / 數據庫級

不同於 QPS 這樣的吞吐量指標，RT 是具有橫向可比性的：例如某個查詢組平時的 RT 都在 1 毫秒內，那麼超過 10ms 的事件應當被視作嚴重的偏差進行分析。

當出現故障時， RT 視圖對於定位原因也很有幫助：如果所有查詢整體 RT 變慢，那麼最有可能與資源不足有關。如果只是特定查詢組的 RT 發生變化，那就更有可能是某些慢查詢導致了問題，應當進一步調查分析。如果 RT 變化的時間點與應用發佈部署吻合，則應當考慮是否要回滾這些部署。

此外，在性能分析，壓力測試，基準測試時，RT 也是最重要的指標。你可以通過對比典型查詢在不同環境（例如不同 PG 大版本、不同硬件、不同配置參數）下的延遲表現來評估系統的性能，並以此爲依據不斷對系統性能進行調整與改進。

RT 是如此重要，以至於 RT 本身又會衍生出許多下游指標來：1 分鐘 / 5 分鐘 / 15 分鐘的均值 µ 與標準差σ自然必不可少；過去 15 分鐘的 ±σ，±3σ 可以用來衡量 RT 的波動範圍，過去 1 小時的 95，99 分位點也很有參考價值。

RT 是評估 OLTP 工作負載的核心指標，怎麼強調它的重要性都不爲過。

平均返回行數

當 M 是 rows 時，我們會得到每次查詢平均返回的行數，單位是行 / 每查詢。對於 OLTP 工作負載來說，典型查詢模式爲點查，即每次查詢返回幾條數據。

按照主鍵查詢單條記錄，平均返回行數穩定爲 1

如果一個查詢組每次查詢向客戶端吐出幾百甚至成千上萬行記錄，那麼應當對其進行審視。如果這是有意而爲之的設計，比如批量加載任務 / 數據轉儲，那麼不需要做什麼。如果這是由應用 / 客戶端發起的請求，那麼可能存在錯誤，比如語句缺少 LIMIT 限制，查詢缺少分頁設計，這樣的查詢應該進行調整修復。

平均共享緩衝區讀取 / 命中

當 M 是 shared_blks_hit + shared_blks_read 時，我們會得到每條查詢 “命中” 與“讀取”共享緩衝區的平均次數，如果將其乘以默認塊大小 8KiB，我們就會得到這類查詢每次執行的“帶寬”，單位是 B/s：每次查詢平均會訪問 / 讀取多少 MB 數據 ？

按照主鍵查詢單條記錄，平均返回行數穩定爲 1

查詢平均訪問的數據量通常與平均返回的行數相匹配，如果你的查詢平均只返回了幾行，卻訪問了成 M 上 G 的數據塊，那你就需要特別注意了：這樣的查詢對於數據冷熱狀態非常敏感，如果所有的塊都在緩衝區中，它的性能可能還說的過去，但如果從磁盤冷啓動，執行時間可能會出現戲劇性的變化。

當然，不要忘記 PostgreSQL 雙緩存問題，所謂 “讀取” 的數據可能已經在操作系統文件系統層面被緩存過一次了。所以你需要與操作系統監控指標，或者 pg_stat_kcache ，pg_stat_io 這些系統視圖相互參照進行分析。

另一種值得關注的模式是此指標的突變，這通常意味着該查詢組的執行計劃可能出現了翻轉 / 劣化，非常值得關注與進一步研究。

平均 WAL 日誌量

當 M 是 wal_bytes 時，我們得到了每條查詢平均生成 WAL 的大小，這是 PostgreSQL 13 新引入的字段。這個指標可以衡量查詢的變更足跡大小，並計算讀寫比例等重要評估參數。

穩定的 QPS 卻有着週期性 WAL 波動，可推斷是 FPI 的影響

另一個用途是優化檢查點 / Checkpoint：如果你觀察到此指標週期性的起伏（週期約等於 checkpoint_timeout），那麼可以通過調整檢查點間距，來優化查詢產生 WAL 的數量。

對調用次數進行微分的指標 dM/dc，可以展現出一類查詢的工作負載特性，對於優化用戶體驗來說非常有用。特別是 RT 乃是性能優化的黃金指標，怎樣強調其重要性都不爲過。

dM/dc 這樣的指標爲我們提供類似重要的絕對值指標，但如果想要找出哪些查詢的優化潛在收益最大，還需要用到 %M 百分比指標。

百分比指標

現在我們來研究第三類指標，百分比指標。即某個查詢組相對於整體工作負載所佔的比例。

百分比指標 M% 爲我們提供了某個查詢組相對於整體工作負載的比例，幫助我們在頻次、時間、I/O 時間 / 次數上時識別出 “主要參與者”，找出潛在優化收益最大的候選查詢組，作爲優先級評定的重要依據。

常用百分比指標 %M 一覽

舉個例子，如果某個查詢組有 1000 QPS  的絕對值，看上去不少；但如果它只佔整個工作負載的 3%，那麼優化此查詢的收益與優先級就沒那麼高了；反之，如果它佔據了整個工作負載的 50% 還要多 —— 如果你有辦法把它優化掉就可以砍掉整個實例吞吐量的半壁江山，優化它的優先級就會非常之高。

常見的優化策略是這樣的：首先把所有查詢組分別按照上面提到的重要指標：calls，total_exec_time，rows，wal_bytes，shared_blks_hit + shared_blks_read，以及 blk_read_time + blk_write_time 在一段時間內的 dM/dt 值進行排序取 TopN （比如 N=10 或者更多），加入優化候選列表中。

按照特定標準，選取待優化的 TopSQL

然後，對於優化候選列表中的每個查詢組，依次分析其 dM/dc 指標，結合具體的查詢語句與慢查詢日誌 / 等待事件進行分析，決定這是不是一個值得優化的查詢。對於決定（Plan）進行優化的查詢，就可以使用後續篇 “微觀優化” 將要介紹的技巧進行調優（Do），並使用監控系統評估優化的效果（Check），總結分析後進入下一個 PDCA 戴明循環，持續進行管理優化。

除了對指標取 TopN 之外，還可以使用可視化的方式。可視化非常有助於從工作負載中識別 “主要貢獻者”，複雜的判斷算法可能還遠比不上人類 DBA 對監控圖形模式的直覺。想要形成比例感，我們可以藉助餅圖，樹圖或者堆疊的時序圖。

將所有查詢組的 QPS 進行堆疊

例如，我們可以使用餅圖來標識過去 1 小時內耗時 / IO 使用最大的查詢，使用二維樹圖（大小代表總耗時，顏色代表平均 RT）來展示一個額外的維度。並用堆疊時序圖來展示比例隨時間的變化關係。

我們也可以直接分析當下的 PGSS 快照，按照不同的關注點進行排序，按照您自己的標準選擇有待優化的查詢即可。

I/O 耗時對於分析查詢毛刺原因很有幫助

總結

最後，讓我們對上面的內容做一個總結。

PGSS 提供了豐富的指標，其中最重要的累積指標可以使用三種方式進行加工處理：

dM/dt ：指標 M 基於時間的微分，揭示了每秒資源使用量，通常用於減少資源消耗的優化目標。

dM/dc：指標 M 基於調用次數的微分，揭示了每次調用的資源使用量，通常用於改善用戶體驗的優化目標。

 %M ：百分比指標展示了查詢組在整個工作負載中所佔的百分比，通常用於平衡工作負載的優化目標。

通常，我們會根據  %M ：百分比指標 Top 查詢選擇高價值的備選優化查詢，並使用 dM/dt dM/dc** 指標進行進一步的評估，確認是否有優化空間和可行性，並評估優化後的效果。如此往復，不斷循環。

理解了宏觀優化的方法論後，我們就可以用這樣的方法去定位優化慢查詢了。這裏給出了一個具體的 《 利用監控系統診斷 PG 慢查詢》的例子。在下一篇中，我們將介紹關於 PostgreSQL 查詢 微觀優化 的經驗技巧。

參考

[1] PostgreSQL HowTO: pg_stat_statements: https://gitlab.com/postgres-ai/postgresql-consulting/postgres-howtos/
[2] pg_stat_statements: https://www.postgresql.org/docs/current/pgstatstatements.html

[3] 利用監控系統診斷 PG 慢查詢

[4] 如何用 Pigsty 監控現有 PostgreSQL (RDS/PolarDB / 自建)？

[5] Pigsty v2.5 發佈：Ubuntu/Debian 支持與監控改版 / 新擴展

[6] PostgreSQL 監控系統 Pigsty 概述

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/VXkpDlUdnKlK3DKtoyg2wA