????去年年中做了一個用戶權(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í)行計劃措伐，評估腳本性能。
