[mysql] [note] mysql 报错Aborted connection

来源：这里教程网时间：2026-03-01 15:35:12 作者：

Aborted connection报错一般分两种，1）Got an error reading communication packets，基本是网络等原因导致。2）Got timeout reading communication packets，原因基本是会话的idle时间达到了数据库指定的timeout时间。这里主要Got an error reading communication packets报错 2021-01-25T05:54:00.746567Z 1172765 [Note] Aborted connection 1172765 to db: 'xx' user: 'root' host: 'xx.xx.5.12' (Got an error reading communication packets) 2021-01-25T06:13:58.256934Z 1174164 [Note] Aborted connection 1174164 to db: 'xx' user: 'root' host: 'xx.xx.5.12' (Got an error reading communication packets) 2021-01-25T06:14:27.452621Z 1174094 [Note] Aborted connection 1174094 to db: 'xx' user: 'root' host: 'xx.xx.5.12' (Got an error reading communication packets) 2021-01-25T06:18:13.795623Z 1174092 [Note] Aborted connection 1174092 to db: 'xx' user: 'root' host: 'xx.xx.5.11' (Got an error reading communication packets) 2021-01-25T06:18:43.059256Z 1171452 [Note] Aborted connection 1171452 to db: 'xx' user: 'root' host: 'xx.xx.5.11' (Got an error reading communication packets) 2021-01-25T06:25:11.992919Z 1174520 [Note] Aborted connection 1174520 to db: 'xx' user: 'root' host: 'xx.xx.5.11' (Got an error reading communication packets)参考文档： https://www.percona.com/blog/2016/05/16/mysql-got-an-error-reading-communication-packet-errors/首先，当发生 “Got an error reading communication packet” 错误时，它都会为 Aborted_clients或 Aborted_connects递增状态计数器，该计数器描述了由于客户端在没有正确关闭连接而中断的情况下中止的连接数，以及尝试连接到MySQL服务器的失败尝试数。这两个错误的可能原因很多（请参见MySQL 手册中的 Aborted_clients increments or Aborted_connects increments 部分）。

在这种情况下，MySQL为Aborted_clients增加状态 counter ，这可能意味着：

客户端成功连接但异常（可能与未正确关闭连接有关）

客户端的sleep时间超过了定义的 wait_timeout或 Interactive_timeout秒数（最终导致连接休眠了wait_timeout秒数，然后该连接被MySQL服务器强行关闭）

客户端异常终止或超出了查询的 max_allowed_packet

以上不是全部问题列表，要根据具体确定导致此问题的原因以及如何解决。

修复MySQL Communication Errors

连接中断错误不容易诊断。就经验来看，大多数情况下它与网络/防火墙问题有关。我们通常在Percona工具包脚本（即 pt-summary / pt-mysql-summary / pt-stalk）的帮助下调查这些问题。这些脚本的输出可能非常有帮助。

导致连接错误中止的一些原因可能是：

大量连接处于MySQL内部数百秒的休眠状态是应用程序在完成工作后没有关闭连接，而是依靠 wait_timeout 来关闭连接的症状之一。建议更改应用程序逻辑以在操作结束时正确关闭连接。

检查以确保 max_allowed_packet的值足够高，并且客户端没有收到“ packet too large”消息。这种情况会中止连接而没有正确关闭它。

另一种可能性是 TIME_WAIT，通过netstat排查 TIME_WAIT，因此我建议确认在应用程序端可以很好地关闭连接。

确保正确提交（开始和提交）事务，以便一旦应用程序“完成”连接后，它将保持干净状态。

确保客户端应用程序不会中断连接。例如，如果PHP将选项 max_execution_time 设置为5秒，则增加 connect_timeout将无济于事，因为PHP将终止脚本。其他编程语言和环境可以具有类似的安全选项。

有可能是DNS问题，检查是否已启用“ skip-name-resolve”，以及是否根据主机的IP地址（而不是主机名）对主机进行了身份验证。

找出应用程序行为异常的一种方法是在代码中添加一些日志记录，以保存应用程序操作以及MySQL连接ID。这样，可以将其与错误行中的连接号相关联。启用审核日志插件，该日志记录连接和查询活动，并在遇到连接异常中止错误后立即检查 Percona审核日志插件。可以检查审核日志以识别哪个查询是罪魁祸首。如果由于某种原因不能使用Audit插件，则可以考虑使用MySQL常规日志-但是，这在加载的服务器上可能会有风险。您应该启用常规日志持续至少几分钟。尽管这给服务器增加了沉重的负担，但错误经常发生，因此您应该能够在日志变得太大之前收集数据。我建议启用带有-f尾部的常规日志，然后在看到日志中的下一个警告时禁用常规日志。从中止的连接中找到查询后，请确定要查询的应用程序部分，并将查询与应用程序的各个部分相关联。

尝试增加MySQL的 net_read_timeout和 net_write_timeout值，看看是否可以减少错误数量。除非网络比较差，否则 net_read_timeout很少会成为问题。可以试调整这些值，因为在大多数情况下，查询是作为单个数据包生成并发送到服务器的，并且应用程序无法切换为做其他事情，而会使服务器保留部分接收到的查询。可以参考文章https://www.percona.com/blog/2007/07/08/mysql-net_write_timeout-vs-wait_timeout-and-protocol-notes/。

由于异常，所以发生中断连接。除非服务器和客户端之间存在网络问题（例如服务器为半双工，而客户端为全双工），否则服务器不会导致连接异常终止--这是网络引起的问题。此类问题应该在网络接口上排查。通过 ifconfig - a 检查 MySQL服务器上输出，以检查是否有错误。

另一种方法是通过 tcpdump。您可以参考此博客文章（ https://www.percona.com/blog/2008/08/23/how-to-track-down-the-source-of-aborted_connects/），以了解如何追踪中止连接的来源。使用MySQL查找潜在的网络问题，超时和资源问题。

可以参考该文章( https://www.percona.com/blog/2011/04/18/how-to-use-tcpdump-on-very-busy-hosts/)在负载的主机上使用 tcpdump非常有用。它为跟踪导致连接中断的TCP交换序列提供了帮助，排查原因。

对于网络问题，请使用ping来计算mysqld所在的计算机与应用程序发出请求的计算机之间的往返时间（RTT）。在客户端和服务器计算机之间发送一个大文件（1GB或更大），使用 tcpdump监视该过程，然后检查传输过程中是否发生错误。重复此测试几次。参考博文http://www.tusacentral.net/joomla/index.php/mysql-blogs/164-effective-way-to-check-the-network-connection-when-in-need-of-a-geographic-distribution-replication-.html。

另外是 netstat - s 每N秒后时间戳一起输出来进行排查（例如，10秒钟，这样你可以涉及 netstat - s 之前和之后从MySQL错误日志中止连接错误输出）。与被中断的连接错误时戳，则可以与共同涉及它的netstat 捕获作为每一个样本的时间戳 netstat的，和其中手表错误计数器下的TcpExt部分增加的netstat - s 。