由於處理連接的方式不同，MySQL 是否比 PostgreSQL 更具可擴展性？
我正在嘗試確定 MySQL 或 PostgreSQL 是否更適合一次可能會受到數千個並發請求的影響的應用程序。
在研究期間，一個突出的事實是 PostgreSQL 為每個連接創建一個新程序，而 MySQL 創建一個新執行緒來處理每個連接。
- 這是否意味著 MySQL 在處理許多並發連接方面比 PostgreSQL 更有效？
- 這種差異對兩個系統的擴展能力有多大影響？這是我應該開始擔心的事情嗎？
我將使用一個過時的例子。假設您有一個網路伺服器，它為一些靜態頁面和帶有數據庫後端的 php 頁面提供服務。過去，預設配置是：
1- Web 客戶端連接並創建 apache 程序/執行緒
2- php 解釋器被實例化
3-數據庫連接打開
4-查詢完成，生成一些html同時發送給客戶端
5-等待所有數據傳輸到客戶端
6-發布php解釋器、數據庫連接和apache程序/執行緒
這在當時不起作用，現在仍然不起作用，因為第 5 步可能需要一段時間。假設您需要 2 毫秒的 SQL 查詢和 10 毫秒的執行 php 來生成響應，並且需要 500 毫秒來完成 HTTP 傳輸。
數據庫連接打開並持續了 500 毫秒，整個 500 毫秒都佔用了數據庫伺服器上寶貴的 RAM 和資源，但實際上只使用了 2 毫秒。這是0.4％的效率。這意味著：如果數據庫連接僅用於在 2ms 內執行查詢，然後釋放給其他客戶端使用，它可以在數據庫伺服器上使用相同數量的 RAM 每秒執行 250 倍的查詢。這也意味著無法擴展的愚蠢配置將在伺服器上使用數百倍的 RAM，而 RAM 是最寶貴的資源：數據庫。這在實踐中意味著它會火上澆油。
webserver 程序和 php 解釋器只做 10ms 的有用工作，但它們會佔用 webserver 上寶貴的 RAM 500ms。那是2%的效率。因此，出於與上述相同的原因，此設置需要比智能設置多 50 倍的網路伺服器 RAM。
智能設置非常簡單，它基本上是一個漏斗。
在漏斗的寬邊，您有許多緩慢的傳入客戶端連接。
在漏斗的小部分，您有一些網路伺服器程序或數據庫連接。
漏斗是像 g-wan 或 lighttpd 這樣的軟體，或者是一個連接池，它：
- 在使用最少資源的同時收集輸入數據，尤其是每個客戶端不使用一個執行緒
- 當有足夠的輸入數據可用於生成響應時，使用池中預先生成的程序來處理它，緩衝響應，並儘快釋放程序
- 在使用最少資源的同時將數據傳輸回客戶端
使用此設置，您的寶貴資源始終在工作而不是等待客戶，因此您需要更少的資源來產生相同數量的輸出。由於打開的數據庫連接很少，理想情況下每個核心只有幾個連接，數據庫伺服器上的爭用、鎖定和上下文切換就會少得多。特別是，鎖的持有時間要短得多。這一切都使數據庫伺服器更快。
所以你問錯了問題，這不是關於在數據庫伺服器崩潰之前你可以擁有多少並發連接。它是關於使用允許您擁有理想數量的數據庫連接的工具，使您的數據庫以最大吞吐量執行，無論漏斗另一端的實際客戶端連接數量如何。
Postgres 確實傾向於更好地擴展，尤其是當您同時進行讀取、寫入和長而復雜的查詢時。