PG優化實戰系列 200 s到毫秒級記錄？

背景

前段時間同事在優化乙個sql，優化效果從最開始的200+s通過sql改寫優化到20s，但是依舊不能滿足現場需求，於是發給我們瞅瞅。

問題解決

表情況tab1是一張大表，一年資料量億級別，已經按年分割槽存在索引 idx1（time1，colx），id唯一

原始sql：

select

count(*) from
(select id from tab1 where time1 between
1511745973
and1606440373
and col1 =
'xx1'
union
select id from tab1 where time1 between
1511745973
and1606440373
and col2 =
'xx2'
union
select id from tab1 where time1 between
1511745973
and1606440373
and col3 = 'xx3') tmp;

以上sql是取3年的資料，可以看到資料量非常大，此時已經失去分割槽表的作用了，就算走idx1索引效果可能會更差。

優化思路

考慮colx的過濾性，在time1過濾性差的情況下，應該考慮執行計畫優先走colx的索引然後再對時間進行過濾。

create

index idx_tab1_col1_time1 on
tab1(col1,time1);
create
index idx_tab1_col2_time1 on
tab1(col2,time1);
create
index idx_tab1_col3_time1 on tab1(col3,time1);

sql改寫：id欄位沒有重複值，可以去掉沒必要的union

select

count(*) from tab1 where (col1 =
'xx1
'or col2 =
'xx2
'or col3 = 'xx3') and time1 between
1511745973
and1606440373;

重新執行耗時變成毫秒級別（具體多少忘了。。）

問題總結：

1

.分割槽適合查詢時只對部分分割槽字段進行過濾的查詢，對於比如人員資訊表這些將失去意義，總而言之就是分割槽就是為了減少對資料的掃瞄，適合對資料週期性淘汰。
2.多列索引的順序直接決定所建索引是否合適，建議過濾性好的做前導列，多列索引如（id1，id2，id3）能用於（id1），（id1，id2），（id1，id2，id3）的查詢
3.pg支援or條件用組合索引（bitmapscan or
）4.盡量避免排序（改寫union，distinct等）

PG系列 訊號量問題彙總

一說明 postgresql資料庫是多程序資料庫，程序和程序之間訪問同乙個共享記憶體時，需要各種各樣的 鎖 機制，通常訊號量 指的就是程序之間的 鎖 需要設定kernel.sem 20 13000 20 130 獨立執行pg 引數的4個資料對應 semmsl semmns semopm semmni...

pg資料庫sql優化總結

pg資料庫用近1年多，操作的資料量也越來越大，生產上也多次出現慢查詢現象，系統在高峰時間cpu使用率衝高達到100 經分析罪魁禍首就是慢查詢了。第一 排查，分析索引 因業務量的增大，很多單錶的記錄數已經超1,2千萬，對於查詢而言，沒有索引將會是災難，不僅cpu的壓力很大，應用預設的資料庫連線池也受到...

Mongodb 實戰優化

mongodb是乙個高效能，可擴充套件資料庫，並具有低延遲，高吞吐率的效能。但是使用過程中難免會有所坑，下面將介紹一些優化方案。以下建議翻譯自 亞馬遜的 performance best practices for mongodb 2015 補充是自己在mongodb實踐中的總結 1 mongodb...