背景
如同其他資料庫一樣，使用時需要注意一些問題，那麼如何使用PG，可以保證長期穩定。
部署形态設計實踐
根據對可靠性、可恢複性、可用性等等的不同要求，選擇部署形态：
1、分布式部署（例如pg+citus插件）
容量上限：100節點以上，PB級。
計算能力上限：100節點以上，6400核以上。
讀寫帶寬上限：100節點以上，200GB/s以上。
RPO：如果每個計算節點都采用多副本存儲，RPO=0。
RTO：如果每個計算節點都采用HA，RTO可以做到1分鐘内。
使用限制：有一些SQL限制。
适應場景：應用代碼可控程度高的情況下，适合TP和AP業務。
2、單節點本地存儲
容量上限：10TB級。
計算能力上限：64核級。
讀寫帶寬上限：2GB/s級。
RPO：RPO無保障。
RTO：RTO無保障。
使用限制：SQL無限制。
适應場景：測試環境，非生産環境，對資料庫RPO，RTO都沒有要求的環境。
3、單節點多副本存儲
容量上限：32TB級。
RPO：單機房RPO=0，（如果存儲支援跨機房多副本，可以做到多機房RPO=0）。
RTO：10分鐘級。
适應場景：非核心場景生産、測試。
4、雙節點共享存儲
RTO：1分鐘級。
适應場景：核心、非核心場景生産。
5、雙節點主備異步複制
容量上限：32TB級（使用遠端存儲），10TB級（使用本機存儲）
RPO：10GB網絡，REDO延遲毫秒級、1MB以内。（支援跨機房部署）。心跳機制可確定RPO < 60秒
适應場景：非核心場景生産。
6、雙節點主備半同步複制
RPO：
無節點或單一節點異常時，可保證RPO=0。
兩個節點都異常時，RPO取決于備份延遲。采用基于PG流複制的持續REDO備份，可以做到RPO毫秒級。
7、三節點及以上多副本全同步複制
小于半數節點異常時，可保證RPO=0。
半數以上節點異常時，RPO取決于 1、10GB網絡，REDO延遲毫秒級、1MB以内。2、備份延遲。采用基于PG流複制的持續REDO備份，可以做到RPO毫秒級。
适應場景：核心場景生産。
8、計算存儲分離（存儲多副本）（比如阿裡雲POLARDB PG）
容量上限：100TB級。
計算能力上限：16節點，1024核級。
讀寫帶寬上限：32GB/s級。
RTO：15秒級。
9、計算存儲分離（存儲多副本）+ 雙機房半同步
10、計算存儲分離（存儲多副本）+ 多機房多副本全同步
11、隻讀節點
适應場景：擴充讀能力。
12、非核心功能
12.1、業務透明的讀寫分離
12.2、跨庫互動
适應場景：跨庫DBLINK，跨庫外部表，跨庫物化視圖。
12.3、單元化
适應場景：多執行個體共享少量資料，多寫。
使用實踐(規約) - 避坑大法
1、連接配接數過多（2000以上），可能導緻性能下降。
建議使用連接配接池（例如應用程式使用連接配接池，或者使用pgbouncer之類的連接配接池）。連接配接到資料庫的連接配接在10倍CPU核數以内，達到最高的處理吞吐能力。
2、大吞吐高并發的短連接配接，性能下降。
建議使用長連接配接。
3、長連接配接，長期不釋放重建。如果連接配接通路了大量中繼資料，可能導緻記憶體占用過大。
建議設定空閑長連接配接釋放機制。確定不會出現大量記憶體霸占的情況。
《PostgreSQL relcache在長連接配接應用中的記憶體霸占"坑"》4、長事務，以及未結束的2PC事務。
最老事務開始後産生的垃圾版本，無法被垃圾回收程序回收。長事務可能導緻垃圾膨脹。
5、業務死鎖
6、檢查點過短
檢查點設定過短，導緻FPW狂寫，性能下降嚴重。
建議max wal size, min wal size設定為shared buffer 2倍以及一半。
7、大記憶體未使用huge page
大記憶體，未設定shared buffer為huge page，可能導緻hash table巨大無比，浪費記憶體，OOM等連鎖反應。
建議32G以上shared buffer，使用huge page。
8、不合理的索引
導緻DML性能下降，SELECT性能下降。
建議删除，或修改索引定義。
9、不合理的SQL
《PostgreSQL 如何查找TOP SQL (例如IO消耗最高的SQL) (包含SQL優化内容) - 珍藏級》10、pending list 未合并過大
使用GIN反向索引，如果寫入量特别大，可能導緻PENDING LIST合并不及時，當有大量PENDING LIST資料時，查詢性能下降急劇。
11、ctype使用錯誤，例如要查詢中文模糊查詢加速（pg_trgm），使用ctype=c會導緻中文模糊查詢無法使用索引。
《PostgreSQL 中英文混合分詞特殊規則(中文單字、英文單詞) - 中英分明》12、資料存放不合理導緻IO放大
例如空間查詢為切片，組必要條件查詢未分區。
《PostgreSQL 空間切割(st_split, ST_Subdivide)功能擴充 - 空間對象網格化 (多邊形GiST優化)》 《PostgreSQL 空間st_contains，st_within空間包含搜尋優化 - 降IO和降CPU(bound box) (多邊形GiST優化)》13、IO太弱，頻繁更新産生垃圾，垃圾回收不及時，膨脹
建議使用SSD硬碟。
14、關閉自動垃圾回收，會導緻垃圾無法自動回收，膨脹。
建議打開自動垃圾回收。
15、長時間鎖等待
業務邏輯問題，長時間鎖等待，可能引發雪崩，連接配接耗盡等問題。
16、長時間大鎖等待，例如在業務系統中高峰期使用DDL語句，可能導緻長時間大鎖等待。引發雪崩。
建議對DDL操作前，加鎖逾時參數，避免雪崩。
17、分區過多，導緻查詢效率下降，連接配接記憶體占用過大。
建議合理的設定分區數，例如對于高并發頻繁操作的表，建議64個以内分區。對于時間分區表，建議不需要查詢的分區或者已經清理資料的分區，從分區中deatch出去，減少優化器壓力。
18、DDOS
如果對外開放了連接配接監聽，即使攻擊者沒有密碼，也可以使用DDOS攻擊來消耗資料庫連接配接，即利用認證逾時的時間視窗，大量建連接配接，等認證逾時，實際上已占用SLOT。導緻連接配接耗盡。
19、濫用超級使用者權限賬号。
建議業務使用普通權限賬号。
20、事務号回卷
如果長事務一直存在并導緻了FREEZE無法當機，超過20億事務後，資料庫為了避免事務号回卷，會強制停庫，需要進入單使用者進行修複。
21、FREEZE風暴
在9.6以前的版本，FREEZE會導緻全表掃描，導緻IO風暴。可以預測和防止。
《PostgreSQL Freeze 風暴預測續 - 珍藏級SQL》 《PostgreSQL freeze 風暴導緻的IOPS飙升 - 事後追溯》 《PostgreSQL的"天氣預報" - 如何預測Freeze IO風暴》 《PostgreSQL 大表自動 freeze 優化思路》22、slot 堵塞
使用slot進行流複制（邏輯或實體）時，未消耗的日志會在資料庫中保留（不會被清理），如果消耗日志很慢可能導緻REDO占用空間巨大，甚至導緻膨脹到占滿磁盤。
有一些SLOT建立後，不需消費它，更加危險。
23、standby feedback
standby 開啟feedback後，standby上面的SQL會回報給主庫，主庫會延遲回收垃圾，減少STANDBY的SQL與REDO APPLY回放沖突。
但是如果垃圾産生較多，并且autovacuum nap time 喚醒很頻繁，會導緻CPU和IO的升高。
《PostgreSQL實體"備庫"的哪些操作或配置，可能影響"主庫"的性能、垃圾回收、IO波動》24、delay vacuum
主庫開啟vacuum delay，并且垃圾産生較多，并且autovacuum nap time 喚醒很頻繁，會導緻CPU和IO的升高。
原因和23一樣。
25、大表分區
《HTAP資料庫 PostgreSQL 場景與性能測試之 45 - (OLTP) 資料量與性能的線性關系(10億+無衰減), 暨單表多大需要分區》内部原理
了解原理後，知道為什麼要這些最佳實踐
《阿裡雲 PostgreSQL 産品生态；案例、開發管理實踐、原理、學習資料、視訊；PG天天象上沙龍記錄 - 珍藏級》 《PostgreSQL 2天教育訓練大綱》監控
《PostgreSQL Oracle 相容性之 - performance insight - AWS performance insight 理念與實作解讀 - 珍藏級》 《PostgreSQL AWR報告(for 阿裡雲ApsaraDB PgSQL)》 《PostgreSQL 實時健康監控 大屏 - 低頻名額 - 珍藏級》 《PostgreSQL 實時健康監控 大屏 - 高頻名額(伺服器) - 珍藏級》 《PostgreSQL 實時健康監控 大屏 - 高頻名額 - 珍藏級》 《PostgreSQL pgmetrics - 多版本、健康監控名額采集、報告》日常維護
《PostgreSQL DBA 日常管理 SQL》教育訓練
體系化教育訓練内容
規範
《PostgreSQL 資料庫開發規範》PostgreSQL 許願連結
您的願望将傳達給PG kernel hacker、資料庫廠商等, 幫助提高資料庫産品品質和功能, 說不定下一個PG版本就有您提出的功能點. 針對非常好的提議，獎勵限量版PG文化衫、紀念品、貼紙、PG熱門書籍等，獎品豐富，快來許願。
開不開森.
![GitHub連夜封殺！這份阿裡 10W 字内部 Java 字面試手冊到底有多強？[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)