您（或数据库管理员）使用 KILL 语句或 mysqladmin kill 命令杀死了正在运行的线程。

您尝试在关闭与服务器的连接后运行查询。这表示应用程序中的逻辑错误，应予以更正。

在不同主机上运行的客户端应用程序没有从该主机连接到 MySQL 服务器所需的权限。

您在客户端遇到了 TCP/IP 连接超时。如果您一直在使用以下命令，可能会发生这种情况：mysql_options(..., MYSQL_OPT_READ_TIMEOUT,...) 或 mysql_options(..., MYSQL_OPT_WRITE_TIMEOUT,...)。在这种情况下，增加超时可能有助于解决问题。

您在服务器端遇到了超时，并且客户端的自动重新连接被禁用（MYSQL 结构中的 reconnect 标志等于 0）。

您使用的是 Windows 客户端，并且服务器在发出命令之前已断开连接（可能是因为 wait_timeout 过期）。

Windows 上的问题是，在某些情况下，MySQL 在写入到服务器的 TCP/IP 连接时不会收到来自操作系统的错误，而是在尝试从连接读取答案时收到错误。

解决此问题的办法是，如果上次查询已经过去很长时间，则在连接上执行 mysql_ping()（这就是 Connector/ODBC 所做的），或者在 mysqld 服务器上设置 wait_timeout，使其实际上永远不会超时。

如果您向服务器发送的查询不正确或太大，也会收到这些错误。如果 mysqld 收到过大或乱序的数据包，它会认为客户端出现问题并关闭连接。如果您需要大型查询（例如，如果您正在处理大型 BLOB 列），您可以通过设置服务器的 max_allowed_packet 变量来增加查询限制，该变量的默认值为 64MB。您可能还需要增加客户端端的最大数据包大小。有关设置数据包大小的更多信息，请参阅 第 B.3.2.8 节，“数据包过大”。

插入大量行的 INSERT 或 REPLACE 语句也会导致此类错误。无论要插入的行数多少，这两种语句都向服务器发送单个请求；因此，您通常可以通过减少每次 INSERT 或 REPLACE 发送的行数来避免错误。

如果主机名解析失败（例如，如果服务器或网络依赖的 DNS 服务器出现故障），您也可能会看到此错误。这是因为 MySQL 依赖主机系统进行名称解析，但无法知道它是否正在工作——从 MySQL 的角度来看，这个问题与任何其他网络超时没有区别。

如果 MySQL 以启用 skip_networking 系统变量的方式启动，您也可能会看到 MySQL 服务器已断开 错误。

另一个会导致此错误的网络问题是，如果您的防火墙阻止了 MySQL 端口（默认端口 3306），从而完全阻止了与 MySQL 服务器的任何连接。

在使用分叉子进程的应用程序中，您也会遇到此错误，这些子进程都试图使用相同的连接到 MySQL 服务器。可以通过为每个子进程使用单独的连接来避免这种情况。

您遇到了一个错误，服务器在执行查询时崩溃了。

说明 MySQL 服务器是否崩溃。您可以在服务器错误日志中找到有关此信息的信息。请参阅 第 B.3.3.3 节，“如果 MySQL 不断崩溃该怎么办”。

如果一个特定的查询导致 mysqld 崩溃，并且您在运行该查询之前使用 CHECK TABLE 检查了相关的表，您能提供一个可复现的测试案例吗？请参考 第 7.9 节， “调试 MySQL”。

MySQL 服务器中 wait_timeout 系统变量的值是多少？ (mysqladmin variables 可以获取该变量的值.)

您是否尝试在启用通用查询日志的情况下运行 mysqld，以确定问题查询是否出现在日志中？ (请参考 第 7.4.3 节， “通用查询日志”.)