[TOC] > [中文文檔14](http://postgres.cn/docs/14/index.html) ## 概述 一般的開發依賴為`Redis + MySQL + Greenplum/Hadoop + Kafuka/Flink + ElasticSearch` 組合,但是使用 pgsql 就可以一個搞定 * **OLTP**：事務處理是PostgreSQL的本行 * **OLAP**：citus分布式插件，ANSI SQL兼容，窗口函數，CTE，CUBE等高級分析功能，任意語言寫UDF * **流處理**：PipelineDB擴展，Notify-Listen，物化視圖，規則系統，靈活的存儲過程與函數編寫 * **時序數據**：timescaledb時序數據庫插件，分區表，BRIN索引 * **空間數據**：PostGIS擴展（殺手锏），內建的幾何類型支持，GiST索引。 * **搜索索引**：全文搜索索引足以應對簡單場景；豐富的索引類型，支持函數索引，條件索引 * **NoSQL**：JSON，JSONB，XML，HStore原生支持，至NoSQL數據庫的外部數據包裝器 * **數據倉庫**：能平滑遷移至同屬Pg生態的GreenPlum，DeepGreen，HAWK等，使用FDW進行ETL * **圖數據**：遞歸查詢 * **緩存**：物化視圖 **優點** DDL能放入事務中，刪表，TRUNCATE，創建函數，索引，都可以放在事務里原子生效，或者回滾。這就能進行很多騷操作，比如在一個事務里通過RENAME，完成兩張表的王車易位。能夠并發地創建或刪除索引（不鎖表）；為表添加新的空字段不鎖表，瞬間完成。這意味著可以隨時在線上按需添加移除索引，添加字段，不影響業務。復制方式多樣：段復制，流復制，觸發器復制，邏輯復制，插件復制，多種復制方法。豐富的復制支持使得不停服務遷移數據變得無比容易。提交方式多樣：異步提交，同步提交，法定人數同步提交。FDW的存在讓ETL變得無比簡單，一行SQL就能解決。系統視圖非常完備，做監控系統相當簡單。 ## Don't Do This > [Don't Do This](https://wiki.postgresql.org/wiki/Don%27t_Do_This) ### 不要在查詢中使用 NOT IN **問題**：NOT IN 在處理大集合時，性能會迅速下降，尤其是當集合中包含 NULL 時，行為可能會不一致。 **解決方案**：使用 LEFT JOIN 或 NOT EXISTS 來替代 NOT IN，這樣可以提高查詢性能并避免潛在的邏輯問題。 ### 不要使用大寫的表名或列名 PostgreSQL 將所有名稱 - 表、列、函數和其他所有內容 - 折疊為小寫，除非它們是 “雙引號”。 ### 不要使用 BETWEEN（尤其是與時間戳一起使用） `BETWEEN`使用封閉區間比較：指定范圍的兩端的值都包含在結果中。 如 ``` SELECT * FROM blah WHERE timestampcol BETWEEN '2018-06-01' AND '2018-06-08' ``` 這將包括時間戳正好為 2018-06-08 00：00：00.000000 的結果，但不包括同一天晚些時候的時間戳。因此，查詢似乎有效，但是一旦你在午夜收到一個條目，你最終就會重復計算它。 正確執行 ``` SELECT * FROM blah WHERE timestampcol >= '2018-06-01' AND timestampcol < '2018-06-08' ``` ### Text storage 文本存儲 盡量直接使用 `TEXT` 類型，而不要過于糾結選擇其他字符串類型（如 `CHAR` 或 `VARCHAR`）。這種建議主要基于 PostgreSQL 對字符串類型的實現方式和其靈活性 * **性能差異極小**： * PostgreSQL 對 `TEXT` 和 `VARCHAR(n)` 的實現是幾乎一樣的，性能上沒有顯著差異。 * 唯一的區別是 `VARCHAR(n)` 會額外檢查長度限制，這可能會稍微增加開銷。 * **靈活性**： * `TEXT` 沒有長度限制，可以處理動態變化的數據需求，而 `VARCHAR(n)` 必須在設計時設定固定長度。 * 避免了將來因修改列定義（比如更改長度限制）而需要遷移數據的麻煩。 * **簡化設計**： * 使用 `TEXT` 避免了對字段長度的預估錯誤（如 `VARCHAR(255)` 的限制過小或過大）。 * 提高代碼和數據庫設計的可維護性。 * **兼容性**： * 某些 ORM（對象關系映射工具）或框架默認將字符串映射為 `TEXT`，例如 Django 就推薦使用 `TEXT`。