????去年年中做了一個用戶權(quán)益的控制功能俗慈,其中查詢用戶權(quán)益歷史記錄接口測試同學(xué)壓測發(fā)現(xiàn)100(線程)*100(循環(huán))的情況出現(xiàn)睛驳,部分請求超過10S相應(yīng)&很大一批數(shù)據(jù)出現(xiàn)超過1S的情況咆瘟。用戶量1000W+,表數(shù)據(jù)2000W+印蔗。多次測試性能差距較大客冈,多次測試發(fā)現(xiàn)的特征是:分頁設(shè)定為(2~5)頁的情況出現(xiàn)并發(fā)性能特別差,分頁設(shè)置為10的情況并發(fā)性能立馬提升赏殃。
1敷待、針對設(shè)定分頁設(shè)定為5的情況
????下面語句索引包含uid、update_date 兩個單獨索引(update_date主要是考慮后續(xù)的數(shù)據(jù)統(tǒng)計和分析使用需要)仁热,PG查詢優(yōu)化器根據(jù)updated_date 進行索引
2榜揖、分頁設(shè)置為10 的情況
查詢計劃是按照uid進行查詢的,根據(jù)uid索引之后的數(shù)據(jù)量就比較小了抗蠢,性能會立馬提升
????根據(jù)explain獲取執(zhí)行計劃之后举哟,查看了測試環(huán)境數(shù)據(jù)的分布情況,發(fā)現(xiàn)數(shù)據(jù)分布集中在update_date某個固定的時間段內(nèi)迅矛。所以分頁選擇limit2并且根據(jù)update_time desc的情況妨猩,PG的查詢優(yōu)化器就會自動選擇update_date作為索引,由于數(shù)據(jù)集中分布在update_date某個時間段诬乞,導(dǎo)致索引之后的數(shù)據(jù)量仍然非常大册赛,需要通過uid進行filter過濾,導(dǎo)致性能非常差震嫉。強制刪除update_date字段的索引之后森瘪,查詢強制走UID索引,性能明顯提升票堵。
PG沒有類似Mysql 強制索引查詢的指令(MySQL使用force?index(update_date))扼睬,故涉及到PG查詢分頁的情況,當(dāng)存在排序和過濾兩個字段均有索引的情況,最好先評估數(shù)據(jù)的分布情況窗宇,看看執(zhí)行計劃措伐,評估腳本性能。