在本節中，還介紹了出現查詢錯誤期間，與丟失了服務器連接有關的事宜。

MySQL服務器不可用錯誤的最常見原因是服務器超時以及連接已關閉。在該情況下，通常能見到下述錯誤代碼之一（具體的錯誤代碼與操作系統有關）：

在默認情況下，如果未發生任何事，8小時后服務器將關閉連接。也可以在啟動mysqld時，通過設置wait_timeout變量更改時間限制。請參見5.3.3節，“服務器系統變量”.

如果有1個腳本，你僅需要再次發出查詢，讓客戶端再次進行自動連接即可。其中，假定在客戶端中啟用了自動再連接功能（對于mysql命令行客戶端，這是默認設置）。

MySQL服務器不可用錯誤的一些其他常見原因如下：

·         你（或db系統管理員）使用KILL語句或mysqladmin kill命令殺死了正在運行的線程。

·         你試圖在關閉了與服務器的連接后運行查詢。這表明應更正應用程序中的邏輯錯誤。

·         你在客戶端一側遇到TCP/IP連接超時錯誤。如果你使用了命令：mysql_options(..., MYSQL_OPT_READ_TIMEOUT,...)或mysql_options(..., MYSQL_OPT_WRITE_TIMEOUT,...)，就可能出現該問題。在該情況下，增加超時值可能有助于問題的解決。

·         你在服務器端遇到超時錯誤，而且禁止了客戶端中的自動再連接功能（MYSQL結構中的再連接標志等于0）。

·         你正在使用Windows客戶端，而且在發出命令之前服務器撤銷了連接（或許是因為已超過wait_timeout）。

在Windows平臺上出現問題的原因，在某些情況下，將TCP/IP連接寫入服務器時，MySQL未收到來自操作系統的錯誤，但當試圖從連接讀取答案時出現錯誤。

在該情況下，即使MYSQL結構中的再連接標志等于1，MySQL也不會執行自動再連接并再次發出查詢，這是因為它不知道服務器是否收到原始查詢。

對此的解決方式是：如果自上一次查詢以來經過了較長時間，在連接上執行mysql_ping（正是MyODBC所作的）；或在mysqld服務器上將wait_timeout設置得很高，使之實際上不存在超時。

·         如果你向服務器發出了不正確或過大的查詢，也會遇到這類問題。如果mysqld收到過大或無序的信息包，它會認為客戶端出錯，并關閉連接。如果需要執行較大的查詢（例如，正在處理大的BLOB列），可通過設置服務器的max_allowed_packet變量，增加查詢限制值，該變量的默認值為1MB。或許，你還需增加客戶端上的最大信息包大小。關于設置信息包大小的更多信息，請參見A.2.9節，“信息包過大”。

·         如果你的客戶端低于4.0.8而且你的服務器高于4.0.8，當你接收16MB或更大的信息包時，可能會丟失連接。

·         如果MySQL是用“--skip-networking”選項啟動的，也會見到MySQL服務器不可用錯誤。

·         你遇到了執行查詢時服務器宕機的缺陷。

通過執行mysqladmin version并檢查服務器的正常工作時間，可檢查服務器是否宕機并重啟。如果客戶端連接是因mysqld崩潰和重啟而斷開的，應將重點放在查找崩潰你方面。首先應再次檢查發出的查詢是否再次殺死了服務器。請參見A.4.2節，“如果MySQL依然崩潰，應作些什么”。

用“--log-warnings=2”選項啟動mysqld，可獲得關于連接的更多信息。這樣，就能將某些斷開連接錯誤記錄到hostname.err文件中。請參見5.11.1節，“錯誤日志”。

如果你打算創建與該問題有關的缺陷報告，務必包含下述信息：

1.    指明MySQL服務器是否宕機。通過服務器錯誤日志可發現這方面的信息。請參見A.4.2節，“如果MySQL依然崩潰，應作些什么”。

2.    如果特定查詢殺死了mysqld，而且在運行查詢前用CHECK TABLE檢查了涉及的表，你是否能提供可重復的測試范例？請參見E.1.6節，“如果出現表崩潰，請生成測試案例”。

3.    在MySQL服務器中，系統變量wait_timeout的值是什么？（mysqladmin variables給出了該變量的值）。

4.    你是否嘗試使用“--log”選項來運行mysqld，以確定是否在日志中出現問題？

另請參見A.2.10節，“通信錯誤和失效連接”。

請參見1.7.1.2節，“請教問題或通報缺陷”。