在 MySQL 错误日志中，我看到这些警告很少：
120611 16:12:30 [Warning] Aborted connection 2619503 to db: 'db_name' user: 'user_name' host: 'webapp_hostname' (Got an error reading communication packets)
本身没有注意到任何数据丢失，所以我想知道这个警告是什么意思，或者是什么原因造成的，以及是否可以解决导致这些问题的问题。这是在 RHEL 6.1 和 MySQL Enterprise 5.5 上。
Rol*_*DBA 69
MySQL 连接的无声杀手之一是 MySQL 数据包。
首先，让我们弄清楚 MySQL 数据包是什么。
根据“了解 MySQL 内部结构”（ISBN 0-596-00957-7）的第 99 页，这里是解释 MySQL 数据包的第 1-3 段：
MySQL 网络通信代码是在查询总是相当短的假设下编写的，因此可以在一个块中发送到服务器并由服务器处理，这在 MySQL 术语中称为数据包。服务器为临时缓冲区分配内存来存储数据包，并请求足够的内存来完全容纳它。这种架构需要采取预防措施以避免服务器内存不足——数据包大小的上限，此选项可实现这一点。
与此选项相关的代码可在sql/net_serv.cc 中找到 。查看my_net_read()，然后按照对my_real_read()的调用并特别注意 net_realloc()。
此变量还限制了许多字符串函数的结果的长度。有关详细信息，请参阅sql/field.cc和 sql/intem_strfunc.cc。
了解有关 MySQL 数据包的这一点允许开发人员/DBA 调整它们的大小以在一个数据包中容纳多个 BLOB，即使它们非常大。当然，在这方面，太小的数据包会导致打开连接的问题。
根据MySQL 文档
如果向服务器发送不正确或过大的查询，也会出现这些错误。如果 mysqld 收到一个太大或乱序的数据包，它会假设客户端出现问题并关闭连接。如果您需要大查询（例如，如果您正在处理大 BLOB 列），您可以通过设置服务器的 max_allowed_packet 变量来增加查询限制，该变量的默认值为 1MB。您可能还需要增加客户端的最大数据包大小。有关设置数据包大小的更多信息，请参见第 C.5.2.10 节“数据包太大”。
插入大量行的 INSERT 或 REPLACE 语句也可能导致此类错误。无论要插入的行数如何，这些语句中的任何一个都会向服务器发送单个请求；因此，您通常可以通过减少每次 INSERT 或 REPLACE 发送的行数来避免该错误。
推荐
尝试将max_allowed_packet提高到更大的数字，因为默认值为 1M。我建议您使用当前数据集中最大的 TEXT 或 BLOB 字段的 10 倍左右。
要将max_allowed_packet 设置为256M，可以将其添加到/etc/my.cnf 或my.ini
[mysqld]
max_allowed_packet=256M
涵盖未来 mysqld 的重启。要立即在服务器上安装该值，请运行以下命令：
SET GLOBAL max_allowed_packet = 1024 * 1024 * 256;
试一试 ！！！
大多数默认情况下 max_connections 将是 100。尝试增加配置参数
max_connections=400，在my.cnf中设置后重启服务器，或者动态设置：
set @@global.max_connections = 400;
只需尝试上述建议即可避免出现此警告消息，并确保您的网络没有丢包。
我最近从 MySQL Enterprise 5.1.x迁移到5.7.x后遇到了这个问题，没有对应用程序进行任何重大代码更改，“注释”就开始出现。
就我而言，出现“注释”的根本原因是程序退出且连接仍然打开。连接未关闭的情况稍微复杂一些，与MySQL无关，而是与ACE、线程和TSS有关。