在本节中，还介绍了出现查询错误期间，与丢失了服务器连接有关的事宜。
MySQL服务器不可用错误的最常见原因是服务器超时以及连接已关闭。在该情况下，通常能见到下述错误代码之一（具体的错误代码与操作系统有关）：
|
错误代码 |
描述 |
|
CR_SERVER_GONE_ERROR |
客户端无法将问题发送至服务器。 |
|
CR_SERVER_LOST |
写入服务器时客户端未收到错误，但也未获得问题的完整答案（或任何答案）。 |
在默认情况下，如果未发生任何事，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节，“通信错误和失效连接”。