2. 程式人生 > >【postgresql案例一】一個LIMIT引發的“血案”

【postgresql案例一】一個LIMIT引發的“血案”

阿新 • • 發佈：2019-02-10

之前給業務排查的時候發現，業務上存在大量的全量查詢，其中很多資訊都是無用的，採用全量查詢存在以下幾個方面問題：

  • 查詢資料量大，導致傳送時間長，在資料庫中經常看到慢查詢日誌，經常需要分析
  • 當前業務採用sqlachemly方式操作資料庫，資料量大的時候，經常出現python接收慢，並且佔用大量記憶體的情況，之前出現過大併發下全量查詢導致客戶端卡死的情況

根據經驗，提出了加上LIMIT的方法，限制每次查詢返回的行數，並且這也是業務社群上提供的方法。但是，萬萬沒有想到，這樣一個小小的LIMIT，竟然導致業務效能下降百倍，生產環境“癱瘓”兩次，真是苦不堪言啊，下面一起看下這個“血案”究竟是怎樣發生的。

查詢SQL介紹

通過對業務模型梳理，簡化後的業務查詢SQL語句如下：

create table T_A(id int, c_1 int);
create index t_a_id on T_A(id);
create index t_a_c on T_A(c_1);
create table T_B(id int, c_1 int);
create index t_b_id on T_B(id);


insert into T_A select generate_series(1,200000),generate_series(1,1000000);
insert into T_A select generate_series(1,200000),generate_series(1,1000000);
insert into T_A select generate_series(1,200000),generate_series(1,1000000);
insert into T_A select generate_series(1,200000),generate_series(1,1000000);
insert into T_A select generate_series(1,200000),generate_series(1,1000000);

truncate table t_b;
insert into T_B select generate_series(1,1000),generate_series(1,10);


vacuum analyze t_a;
vacuum analyze t_b;

查詢SQL如下：

explain (analyze,buffers,verbose) select T_A.id from T_A left outer join T_B on T_A.id=T_B.id
where (T_A.c_1 = 999 or T_B.c_1=1 ) order by T_A.id ASC limit 4000;

執行結果

目前使用的是PG9.2的主幹版本，首先在該版本上測試：

postgres=# explain (analyze,buffers,verbose) select T_A.id from T_A left outer join T_B on T_A.id=T_B.id
where (T_A.c_1 = 999 or T_B.c_1=1 ) order by T_A.id ASC limit 4000;postgres-#
                                                                     QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.42..96110.03 rows=4000 width=4) (actual time=0.023..4798.584 rows=2505 loops=1)
   Output: t_a.id
   Buffers: shared hit=4977865 read=40181 written=2720
   ->  Merge Left Join  (cost=0.42..12013798.38 rows=500004 width=4) (actual time=0.023..4798.168 rows=2505 loops=1)
         Output: t_a.id
         Merge Cond: (t_a.id = t_b.id)
         Filter: ((t_a.c_1 = 999) OR (t_b.c_1 = 1))
         Rows Removed by Filter: 4997495
         Buffers: shared hit=4977865 read=40181 written=2720
         ->  Index Scan using t_a_id on public.t_a
 
  (cost=0.00..12000762.83 rows=5000000 width=8) (actual time=0.008..3570.243 rows=5000000 loops=1)
               Output: t_a.id, t_a.c_1
               Buffers: shared hit=4977856 read=40181 written=2720
         ->  Materialize  (cost=0.00..45.75 rows=1000 width=8) (actual time=0.009..3.625 rows=24976 loops=1)
               Output: t_b.id, t_b.c_1
               Buffers: shared hit=9
               ->  Index Scan using t_b_id on public.t_b  (cost=0.00..43.25 rows=1000 width=8) (actual time=0.007..0.413 rows=1000 loops=1)
                     Output: t_b.id, t_b.c_1
                     Buffers: shared hit=9
 Total runtime: 4798.890 ms
(19 rows)

postgres=# select version();
                                                     version
-----------------------------------------------------------------------------------------------------------------
 PostgreSQL 9.2.24 on aarch64-unknown-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11), 64-bit
(1 row)

從上面的執行計劃中，可以看出，優化器在對OR條件進行選擇的時候，採用的是index scan的方式，對錶t_a的掃描消耗了3.57s。

對比下，去掉LIMIT的執行計劃

postgres=# explain (analyze,buffers,verbose) select T_A.id from T_A left outer join T_B on T_A.id=T_B.id
where (T_A.c_1 = 999 or T_B.c_1=1 ) order by T_A.id ASCpostgres-# ;
                                                            QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------
 Sort  (cost=152278.05..153528.06 rows=500004 width=4) (actual time=2409.779..2410.012 rows=2505 loops=1)
   Output: t_a.id
   Sort Key: t_a.id
   Sort Method: quicksort  Memory: 214kB
   Buffers: shared hit=3149 read=18983
   ->  Hash Left Join  (cost=27.50..91270.73 rows=500004 width=4) (actual time=0.514..2408.678 rows=2505 loops=1)
         Output: t_a.id
         Hash Cond: (t_a.id = t_b.id)
         Filter: ((t_a.c_1 = 999) OR (t_b.c_1 = 1))
         Rows Removed by Filter: 4997495
         Buffers: shared hit=3146 read=18983
         ->  Seq Scan on public.t_a  (cost=0.00..72124.00 rows=5000000 width=8) (actual time=0.030..809.089 rows=5000000 loops=1)
               Output: t_a.id, t_a.c_1
               Buffers: shared hit=3144 read=18980
         ->  Hash  (cost=15.00..15.00 rows=1000 width=8) (actual time=0.463..0.463 rows=1000 loops=1)
               Output: t_b.id, t_b.c_1
               Buckets: 1024  Batches: 1  Memory Usage: 40kB
               Buffers: shared hit=2 read=3
               ->  Seq Scan on public.t_b  (cost=0.00..15.00 rows=1000 width=8) (actual time=0.003..0.198 rows=1000 loops=1)
                     Output: t_b.id, t_b.c_1
                     Buffers: shared hit=2 read=3
 Total runtime: 2410.330 ms
(22 rows)

從執行計劃上可以看到，這裡採用的是全表掃描方式，耗時只有809ms。

是的，全表掃描只有809ms，索引掃描耗時3.57ms，這部分時間差距是整個語句的差距，沒有看錯。

由於目前使用的是PG92版本，再測試一個PG9.6.8的版本

postgres=# explain analyze select T_A.id from T_A left outer join T_B on T_A.id=T_B.id
where (T_A.c_1 = 999 or T_B.c_1=1 ) order by T_A.id ASC limit 4000;postgres-# ;
                                                                 QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=1.75..1992.77 rows=4000 width=4) (actual time=0.024..4631.075 rows=2505 loops=1)
   ->  Merge Left Join  (cost=1.75..248880.44 rows=500004 width=4) (actual time=0.023..4630.797 rows=2505 loops=1)
         Merge Cond: (t_a.id = t_b.id)
         Filter: ((t_a.c_1 = 999) OR (t_b.c_1 = 1))
         Rows Removed by Filter: 4997495
         ->  Index Scan using t_a_id on t_a  (cost=0.43..235843.67 rows=5000000 width=8) (actual time=0.009..3393.133 rows=5000000 loops=1)
         ->  Materialize  (cost=0.28..45.77 rows=1000 width=8) (actual time=0.009..2.465 rows=24976 loops=1)
               ->  Index Scan using t_b_id on t_b  (cost=0.28..43.27 rows=1000 width=8) (actual time=0.008..0.384 rows=1000 loops=1)
 Planning time: 0.586 ms
 Execution time: 4631.266 ms
(10 rows)

postgres=# select version();
                                                    version
----------------------------------------------------------------------------------------------------------------
 PostgreSQL 9.6.8 on aarch64-unknown-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11), 64-bit
(1 row)

發現加上LIMIT之後，執行時間差不多，採用的仍然是索引掃描方式（本地測試，PG10不存在這個問題，一方面存在並行查詢，二是有優化，關閉並行查詢之後，採用hash join的方式，不會選擇index scan）。

問題分析

仔細分析這個SQL語句，整個語句比較簡單，但是存在一個OR語法，並且是兩個不同的表：

 select T_A.id from T_A left outer join T_B on T_A.id=T_B.id where (T_A.c_1 = 999 or T_B.c_1=1 ) order by T_A.id ASC limit 4000;

查詢資料，分析執行計劃變慢的原因可能是：

由於後面存在order by id limit  4000，優化器認為只需要獲取id的前4000條元組即可，並且id是主鍵，因此會預設選擇id的索引掃描，認為這種方式是最快的，但不幸的是，由於前面是帶有OR的條件判斷，並且值和id無關，因此需要遍歷元組判斷是否滿足條件，導致掃描的檔案塊增多（每次從索引找到對應的元組是否滿足條件），從而效能下降。當然，這個語句只有在大資料量下，存在執行計劃發生變化。

如果採用LIMIT 400000條件，執行計劃如下：

postgres=# explain analyze select T_A.id from T_A left outer join T_B on T_A.id=T_B.id
where (T_A.c_1 = 999 or T_B.c_1=1 ) order by T_A.id ASC limit 400000;postgres-#
                                                           QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=145439.95..146439.95 rows=400000 width=4) (actual time=1976.531..1977.094 rows=2505 loops=1)
   ->  Sort  (cost=145439.95..146689.96 rows=500004 width=4) (actual time=1976.530..1976.848 rows=2505 loops=1)
         Sort Key: t_a.id
         Sort Method: quicksort  Memory: 214kB
         ->  Hash Left Join  (cost=27.50..91271.62 rows=500004 width=4) (actual time=0.445..1975.517 rows=2505 loops=1)
               Hash Cond: (t_a.id = t_b.id)
               Filter: ((t_a.c_1 = 999) OR (t_b.c_1 = 1))
               Rows Removed by Filter: 4997495
               ->  Seq Scan on t_a  (cost=0.00..72124.00 rows=5000000 width=8) (actual time=0.037..559.274 rows=5000000 loops=1)
               ->  Hash  (cost=15.00..15.00 rows=1000 width=8) (actual time=0.394..0.394 rows=1000 loops=1)
                     Buckets: 1024  Batches: 1  Memory Usage: 48kB
                     ->  Seq Scan on t_b  (cost=0.00..15.00 rows=1000 width=8) (actual time=0.004..0.153 rows=1000 loops=1)
 Planning time: 1.164 ms
 Execution time: 1977.321 ms
(14 rows)

看到執行返回結果一致，從索引掃描變回順序掃描，從merge join變成hash join，執行時間大大減少。

最後，經過細緻分析，建議業務在ORDER BY上增加一個沒有影響的排序列，如ORDER BY T_A.id，T_A.c_1

執行計劃如下：

postgres=# explain analyze select T_A.id from T_A left outer join T_B on T_A.id=T_B.id
where (T_A.c_1 = 999 or T_B.c_1=1 ) order by T_A.id ASC,T_A.c_1 ASC limit 4000;postgres-#
                                                           QUERY PLAN

-------------------------------------------------------------------------------------------------------
--------------------------
 Limit  (cost=123686.35..123696.35 rows=4000 width=8) (actual time=1921.081..1921.665 rows=2505 loops=1
)
   ->  Sort  (cost=123686.35..124936.36 rows=500004 width=8) (actual time=1921.081..1921.401 rows=2505
loops=1)
         Sort Key: t_a.id, t_a.c_1
         Sort Method: quicksort  Memory: 214kB
         ->  Hash Left Join  (cost=27.50..91271.62 rows=500004 width=8) (actual time=0.402..1919.781 ro
ws=2505 loops=1)
               Hash Cond: (t_a.id = t_b.id)
               Filter: ((t_a.c_1 = 999) OR (t_b.c_1 = 1))
               Rows Removed by Filter: 4997495
               ->  Seq Scan on t_a  (cost=0.00..72124.00 rows=5000000 width=8) (actual time=0.063..565.
419 rows=5000000 loops=1)
               ->  Hash  (cost=15.00..15.00 rows=1000 width=8) (actual time=0.330..0.330 rows=1000 loop
s=1)
                     Buckets: 1024  Batches: 1  Memory Usage: 48kB
                     ->  Seq Scan on t_b  (cost=0.00..15.00 rows=1000 width=8) (actual time=0.005..0.11
7 rows=1000 loops=1)
 Planning time: 0.330 ms
 Execution time: 1921.997 ms
(14 rows)

這樣修改之後，不影響查詢結果，執行計劃和之前保持一致，但是需要注意的是，不能再T_A表的（id，c_1）上建立組合索引，否則和之前一樣，執行計劃發生改變。

結束語

這個問題在我們的生產環境上出現了2次，後來排查，又發現了類似的問題，修改之後，效能沒有下降。並且在mysql5.5上測試，發現類似同樣的情況。

後來分析，最優的解決方式應該是採用UNION ALL的方式轉換OR條件，但是目前pg底層不能自動轉換。可喜的是，社群已經注意到這個問題，著手開發pacth進行底層效能優化，這樣效能會明顯提升

Convert join OR clauses into UNION queries

https://commitfest.postgresql.org/18/1001/

由於對資料庫底層的執行計劃不是很瞭解，因此對這個執行計劃改變過程不是很理解，希望高手能給解答下。

相關推薦

【postgresql案例一】一個LIMIT引發的“血案”

之前給業務排查的時候發現，業務上存在大量的全量查詢，其中很多資訊都是無用的，採用全量查詢存在以下幾個方面問題：查詢資料量大，導致傳送時間長，在資料庫中經常看到慢查詢日誌，經常需要分析當前業務採用sqlachemly方式操作資料庫，資料量大的時候，經常出現python接收慢，並

【案例一】移動端購物車基本功能實現，具體操作類似淘寶購車。

還是直接上圖：        這個效果圖很酷炫~  有個坑紀念下，本來想用jquery-weui做的，然後各種倒騰，還是用css+div，媽耶！ 關鍵核心的jquery語句控制： //繫結全選的按鈕，讓所有購物車都選中，然後計算總數 $("#checkboxSum

【PHP學習筆記】一個基於PHP的簡版後臺HTTP介面測試案例

專案越寫越大，多多少少會有點不敢運行了，就像下面這幅圖一樣（皮一下^ . ^） 不過還是得硬著頭皮去測試，手動測試？是有點浪費時間了，，在此分享一個自動測試的小指令碼，僅供參考。 公共方法 <?php /** * Created by PhpStorm. * Use

【小家java】一個基於POI的Excel的匯入、匯出工具處理類（支援xls，xlsx格式），另有SpringMVC的匯入、匯出案例講解

相關閱讀 前言 表格的匯入、匯出可謂開發過程中經常會碰到的功能。然後這種模版化的東西並不需要每次都去編碼一次，因此我就整理了一個Excel的萬能處理類。能夠實現相容2003、2007的各種Excel格式的匯入匯出功能，使用起來也非常的方面，適用於所有業務場景

【CS229筆記一】監督學習，線性回歸，LMS算法，正態方程，概率解釋和局部加權線性回歸

中心 sqrt 情況 pst 預測 更新 然而 回歸 gauss 監督學習 對於一個房價預測系統，給出房間的面積和價格，以面積和價格作坐標軸，繪出各個點。 定義符號： \(x_{(i)}\)表示一個輸入特征\(x\)。 \(y_{(i)}\)表示一個輸出目標\(y\)。

【數據庫】- 一個值只有0和1的字段，到底要不要建索引？

什麽 是你 美國 www 依次 https 數據庫索引 查詢 .html 關於數據庫索引的所有文章，都會告訴你不要對這種字段建索引。 但這些文章不會告訴你的一個事實是： 如果表裏面這個字段的值分布極度不均勻的情況下，而且你需要查詢分布較少的記錄的話，索引就非常有用了

【10.21總結】一個滲透測試練習例項——發現未知的漏洞(Race condition)

Write-up地址：Exploiting an unknown vulnerability 作者：Abhishek Bundela 　　這篇文章跟我之前看到的文章不太一樣，作者是按照一個練習的方式簡單描述了他對一個應用進行滲透測試的過程，其中提到的許多測試雖然沒有成功，但是對於像我這樣的菜鳥來說還是有很

【10.20總結】一個漏洞提交頁面的提權漏洞

！！！寫完之後網頁崩潰了，然後草稿找回的內容還不對！！！ Write-up地址：Add comment on a private Oculus Developer bug report  漏洞起源於作者Sarmad Hassan (Juba Baghdad)對Oculus網站漏洞（非安全漏洞

【TOP100案例專訪】噹噹網工程師林嘉琦談雙11大促經驗及APM實踐

導讀：第七屆TOP100全球軟體案例研究峰會將於11月30日-12月3日在北京國家會議中心舉辦，本屆峰會以“釋放AI生產力 讓組織向智慧化演進”為開幕式主題，旨在推動企業在趨勢下擁抱AI、探索和思考AI帶來的力量。十八個主題專場，120個案例為組織形式，意在向參會者解讀2018年軟體研發設計創新案例

【docker學習一】CentOS7.5+Docker安裝及使用「安裝、檢視、pull、建立、進入映象」

記錄安裝配置以及使用的過程，可能會有多處摘抄，已註明照抄地址，侵刪。   是什麼：個人理解，是一種移植性很強的虛擬機器，支援版本控制（類似於git），同一個伺服器可以執行多個docker容器，每個docker容器都有一個獨立的虛擬環境。 本人環境： 虛擬機器：Oracle

【軟件測試】一個冬天，如何從手工測試轉職成為測試開發？

後來 -o 嚴格 並且 新功能 app 生產環境 培養 什麽 在回答這個問題之前我們先回答其他一些問題。 測試人員的職能是什麽？ 我認為是質量保障。一個測試人員，無論你是手工點來點去，還是用自動化進行一些模擬操作，他們的核心職能都是相同的，那就是保證項目或產品的質量。如果你

【NOJ1002】【演算法實驗一】【分治演算法】歸併排序

1002.歸併排序 時限：1000ms 記憶體限制：10000K  總時限：3000ms 描述 給定一個數列，用歸併排序演算法把它排成升序。 輸入 第一行是一個整數n（n不大於10000），表示要排序的數的個數； 下面一行是用空格隔開的n個整數。 輸出

【Java必會】一個保姆與兩隻寵物的“代理”故事（動態代理）

文章導航： 文章目的： 1、介紹什麼是代理 2、如何理解“代理” 3、代理有哪些實現方式 什麼是代理？ 在講解Java代理之前我們先要搞明白什麼是“代理”? 代理：法律上指以他人的名義，在授權範圍內進行對被代理人直接發生法律效力的法律行為。 1.短時間代人擔任職

【Appnium 小試牛刀一】根據元素係數座標，計算不同機型相對座標，進行元素點選操作

package main; import io.appium.java_client.AppiumDriver; import java.net.URL; import java.util.concurrent.TimeUnit; import org.openqa.sel

【工具集 一】PL\SQL developer

注意：oracle客戶端和pl/sql developer 是相同的位數，32位都是32位，64位都是64位，不然會報錯。 一.SQL*PLUS客戶端工具 1.下載,網址為:http://www.oracle.com/technetwork/database/featur

【Spring筆記一】Hello，Spring

Spring簡述         Spring是一個主流的Java Web開發框架，該框架是一個輕量級的開源框架，它是為了解決企業應用開發的複雜性問題而產生的。輕量級並不是指它的 jar包有多大，而是指 Spring是非侵入性的，也就是用 Spring時，不需要實現 Sp

【JiYF笨男孩】一個有理想，有目標的笨男孩！

網路名稱：笨男孩 真實姓名：JiYF 所屬行業：工控領域 其它部落格：部落格園 http://www.cnblogs.com/JiYF/ 當前職位：軟體工程師 當前公司：北京xxxx研發中心 個人目標：開源領域有自己的小作品 詳細介紹：目前有3年多

【CSS筆記一】開始學習CSS，為網頁新增樣式

一、認識CSS樣式 CSS全稱為“層疊樣式表 (Cascading Style Sheets)”，它主要是用於定義HTML內容在瀏覽器內的顯示樣式，如文字大小、顏色、字型加粗等。 如下列程式碼：

【一道面試題】一個".java"原始檔中是否可以包括多個類（不是內部類）？有什麼限制？

這個面試題的答案在網上一搜一大把 但都是兩句話就結束了，我們來仔細看一下具體是什麼情況！ 首先 肯定的一點是一個.java的原始檔中是可以包含多個類的，但是public類只能有一個，並且類名要和檔名相同，如果有兩個public類 就會報出以下的錯誤 這

【職場心路】一個老DBA的自白

舉個非常小的例子，05年的某一天，統一企業的吳同學打電話給我，老楊，我們有個系統，業務的反饋，本地登陸沒問題，但是遠端登陸就報密碼錯，業務的人急得不得了。聽著這個問題挺妖怪的不是？客戶現場不可以VPN，那時候好像還沒有TeamViewer，連過去看環境沒可能，上海到崑山少說也要2個小時，客戶還挺急。當時恰好