文件首頁
MySQL 9.0 參考手冊
相關文件 下載本手冊
PDF (US Ltr) - 40.0Mb
PDF (A4) - 40.1Mb
Man Pages (TGZ) - 258.2Kb
Man Pages (Zip) - 365.3Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb


7.1.12.1 連線介面

本節描述 MySQL 伺服器如何管理用戶端連線的各個方面。

網路介面和連線管理執行緒

伺服器能夠監聽多個網路介面上的用戶端連線。連線管理執行緒處理伺服器監聽之網路介面上的用戶端連線請求。

  • 在所有平台上,一個管理執行緒處理 TCP/IP 連線請求。

  • 在 Unix 上,同一個管理執行緒也處理 Unix socket 檔案連線請求。

  • 在 Windows 上,一個管理執行緒處理共用記憶體連線請求,另一個處理具名管道連線請求。

  • 在所有平台上,可以啟用額外的網路介面以接受管理 TCP/IP 連線請求。此介面可以使用處理 一般 TCP/IP 請求的管理執行緒,或使用單獨的執行緒。

伺服器不會建立執行緒來處理它不監聽的介面。例如,沒有啟用具名管道連線支援的 Windows 伺服器不會建立執行緒來處理這些連線。

個別的伺服器外掛程式或元件可能會實作它們自己的連線介面。

用戶端連線執行緒管理

連線管理執行緒將每個用戶端連線與專用於處理該連線驗證和請求處理的執行緒建立關聯。管理執行緒會在必要時建立新的執行緒,但會先查詢執行緒快取,看看其中是否包含可供連線使用的執行緒,以避免建立新執行緒。當連線結束時,如果快取未滿,則其執行緒會傳回至執行緒快取。

在此連線執行緒模型中,目前連線的用戶端有多少,就會有多少執行緒,當伺服器工作負載必須擴展以處理大量連線時,這會有一些缺點。例如,執行緒建立和處置會變得昂貴。此外,每個執行緒都需要伺服器和核心資源,例如堆疊空間。為了容納大量同時連線,每個執行緒的堆疊大小必須保持較小,這會導致堆疊太小或伺服器消耗大量記憶體的情況。其他資源也可能會耗盡,而且排程開銷可能會變得很大。

MySQL Enterprise Edition 包含一個執行緒池外掛程式,提供了一種替代的執行緒處理模型,旨在減少額外負荷並提升效能。它實作了一個執行緒池,透過有效地管理大量用戶端連線的陳述式執行緒,來提升伺服器的效能。請參閱第 7.6.3 節, 「MySQL Enterprise 執行緒池」

為了控制和監控伺服器如何管理處理用戶端連線的執行緒,有幾個系統和狀態變數是相關的。(請參閱第 7.1.8 節,「伺服器系統變數」,以及第 7.1.10 節,「伺服器狀態變數」。)

  • thread_cache_size 系統變數決定了執行緒快取的容量。預設情況下,伺服器會在啟動時自動調整此值,但可以明確設定以覆寫此預設值。值為 0 會停用快取,這會導致為每個新的連線建立一個執行緒,並在連線終止時處置該執行緒。若要啟用快取 N 個閒置的連線執行緒,請在伺服器啟動時或執行階段將 thread_cache_size 設定為 N。當與其關聯的用戶端連線終止時,連線執行緒會變成閒置狀態。

  • 若要監控快取中的執行緒數量,以及因為無法從快取中取得執行緒而建立的執行緒數量,請檢查 Threads_cachedThreads_created 狀態變數。

  • 當執行緒堆疊太小時,會限制伺服器可以處理的 SQL 陳述式的複雜性、儲存程序的遞迴深度,以及其他消耗記憶體的操作。若要為每個執行緒設定 N 個位元組的堆疊大小,請在啟動伺服器時將 thread_stack 設定為 N

連線量管理

若要控制伺服器允許同時連線的最大用戶端數量,請在伺服器啟動時或執行階段設定 max_connections 系統變數。如果嘗試同時連線的用戶端數量超過伺服器設定可處理的數量,則可能需要增加 max_connections(請參閱第 B.3.2.5 節,「連線過多」)。如果伺服器因為達到 max_connections 限制而拒絕連線,則會遞增 Connection_errors_max_connections 狀態變數。

mysqld 實際上允許 max_connections + 1 個用戶端連線。額外的連線保留給擁有 CONNECTION_ADMIN 權限(或已棄用的 SUPER 權限)的帳戶使用。透過將權限授予管理員,而不授予一般使用者(他們應該不需要該權限),管理員可以連線到伺服器並使用 SHOW PROCESSLIST 來診斷問題,即使已連線的最大非特權用戶端數量也是如此。請參閱第 15.7.7.30 節,「SHOW PROCESSLIST 陳述式」

伺服器也允許在管理網路介面上建立管理連線,您可以使用專用的 IP 位址和連接埠進行設定。請參閱第 7.1.12.2 節,「管理連線管理」

群組複寫外掛程式使用內部工作階段與 MySQL 伺服器互動,以執行 SQL API 操作。群組複寫的內部工作階段與用戶端連線分開處理,因此它們不計入 max_connections 限制,並且如果伺服器已達到此限制,也不會被拒絕。

MySQL 支援的最大用戶端連線數量(也就是 max_connections 可以設定的最大值)取決於幾個因素

  • 給定平台上執行緒庫的品質。

  • 可用的 RAM 容量。

  • 每個連線使用的 RAM 容量。

  • 每個連線的工作負載。

  • 所需的響應時間。

  • 可用的檔案描述元數量。

Linux 或 Solaris 應該能夠常規地支援至少 500 到 1000 個同時連線,如果有數 GB 的可用 RAM,並且每個連線的工作負載較低或響應時間目標不嚴格,則可以支援多達 10,000 個連線。

增加 max_connections 值會增加 mysqld 需要的檔案描述元數量。如果可用的描述元數量不足,伺服器會減少 max_connections 的值。有關檔案描述元限制的評論,請參閱第 10.4.3.1 節,「MySQL 如何開啟和關閉資料表」

可能需要增加 open_files_limit 系統變數,這也可能需要提高作業系統對 MySQL 可以使用的檔案描述元數量的限制。請查閱您的作業系統文件,以確定是否可以增加限制以及如何增加限制。另請參閱第 B.3.2.16 節,「找不到檔案和類似錯誤」