介紹

您有沒有遇到這樣的問題：已經重啟了 PostgreSQL 服務器，但是第二次運行同樣的查詢仍然快得多，這是為什么？lRh28資訊網——每日最新資訊28at.com

這個問題的答案很簡單，因為重新啟動數據庫服務器只會清除數據庫緩沖區的緩存，但是其他緩存沒有變化，這些緩存是：lRh28資訊網——每日最新資訊28at.com

緩沖區緩存 - PostgreSQL 從磁盤加載包含表和索引的頁面的共享緩沖池，以直接從內存工作，從而減少磁盤訪問。lRh28資訊網——每日最新資訊28at.com

頁面緩存 - 操作系統通常會緩存文件 IO，除非您通過使用 O_DIRECT 標志，或者以直接 IO 模式掛載文件系統，來顯式跳過頁面緩存。lRh28資訊網——每日最新資訊28at.com

硬件緩存 - CPU 狀態緩存可能會輕微地影響到查詢執行速度，但硬件 IO 緩存可能會造成巨大影響。其中一個是硬件 RAID 緩存，但更重要的是 SAN 緩存，它可能影響非常大。lRh28資訊網——每日最新資訊28at.com

準備工作

讓我們通過一個示例來更好地了解，頁面緩存會如何影響查詢性能。lRh28資訊網——每日最新資訊28at.com

假設我們有一個名為t1的表：lRh28資訊網——每日最新資訊28at.com

CREATE TABLE t1 (id integer, str text);

下面是用于生成數據的示例 SQL 查詢：lRh28資訊網——每日最新資訊28at.com

我們已經給此表填充了數百萬行示例數據。lRh28資訊網——每日最新資訊28at.com

頁面緩存示例

在我們觀察頁面緩存對查詢性能的影響之前，我們需要先停止 PostgreSQL 服務器，首先以 root 帳戶清理系統頁面緩存：lRh28資訊網——每日最新資訊28at.com

# echo 3 > /proc/sys/vm/drop_caches

然后，啟動 PostgreSQL 服務器。lRh28資訊網——每日最新資訊28at.com

現在，假設我們要檢索總共的記錄數：lRh28資訊網——每日最新資訊28at.com

SET max_parallel_workers_per_gather TO 0;PLAIN (analyze, buffers) SELECT count(*) FROM t1;                                                     QUERY PLAN-------------------------------------------------------------------------------------------------------------------- Aggregate  (cost=32909.00..32909.01 rows=1 width=8) (actual time=439.977..439.978 rows=1 loops=1)   Buffers: shared read=20409   ->  Seq Scan on t1  (cost=0.00..30409.00 rows=1000000 width=0) (actual time=0.244..349.652 rows=1000000 loops=1)         Buffers: shared read=20409 Planning:   Buffers: shared hit=13 read=6 Planning Time: 3.522 ms Execution Time: 440.979 ms(8 rows)

表現很好。讓我們重新啟動 PostgreSQL 服務器。lRh28資訊網——每日最新資訊28at.com

實際上，我們可以通過 pgfincore 來查看頁面緩存的統計信息。lRh28資訊網——每日最新資訊28at.com

現在，讓我們再次檢索記錄總數，看看它會如何影響性能：lRh28資訊網——每日最新資訊28at.com

SET max_parallel_workers_per_gather TO 0;EXPLAIN (analyze, buffers) SELECT count(*) FROM t1;                                                     QUERY PLAN-------------------------------------------------------------------------------------------------------------------- Aggregate  (cost=32909.00..32909.01 rows=1 width=8) (actual time=199.904..199.906 rows=1 loops=1)   Buffers: shared read=20409   ->  Seq Scan on t1  (cost=0.00..30409.00 rows=1000000 width=0) (actual time=1.131..113.739 rows=1000000 loops=1)         Buffers: shared read=20409 Planning:   Buffers: shared hit=13 read=6 Planning Time: 0.413 ms Execution Time: 199.955 ms(8 rows)

現在查詢性能明顯更好。我們已將執行時間縮短了兩倍以上！lRh28資訊網——每日最新資訊28at.com

本文鏈接：http://m.www897cc.com/showinfo-26-80342-0.html系統頁面緩存也會影響數據庫的運行性能，你相信嗎？

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇： Node.js 新官網為何選用了 Next.js?

下一篇： 大型企業通常如何進行單元測試？