我在 mysql 中收到此警告，
[Warning] Aborted connection 21 to db: 'MyDB' user: 'MyUser' host: 'localhost' (Got an error reading communication packets)
我经历过谷歌几个主题，并根据一些建议，我增加了max_allowed_packet从128 to 512 to 1024仍然相同的行为。
我使用的Drupal 7，和是有很多BLOB数据类型的，但1024 Mb的max_allowed_packet应该是足够的在我看来。
任何其他解决方法如何克服此警告？
编辑：
添加了一些设置作为@Rolando 的建议/答案，我仍然收到相同的警告。
我的 mysql 配置如下所示：
[client]
port = 3306
socket = /tmp/mysql.sock
default-character-set = utf8
[mysqld]
port = 3306
socket = /tmp/mysql.sock
skip-external-locking
key_buffer_size = 16K
max_allowed_packet = 1024M
table_open_cache = 128
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length …我正在使用 MySQL 数据库来存储文件。
我使用的表结构如下：
+--------------+----------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------------+----------+------+-----+---------+-------+
| AttachmentID | int(11) | NO | PRI | NULL | |
| Data | longblob | NO | | NULL | |
+--------------+----------+------+-----+---------+-------+
INSERT我使用的命令尽可能简单：
INSERT INTO table (AttachmentID, Data) VALUES (attachmentID, attachmentData);
很明显， whereattachmentID是一个int，并且attachmentData是一个大字节数组。
阅读了关于如何在数据库中存储文件的几个指南后，我max_allowed_packet将配置文件中的设置增加到“512M”，对于我实际插入的文件来说已经足够了。
这适用于 30MB - 40MB 的几个文件。但是，现在我要插入 90MB+ 范围内的较大文件，我收到“内存不足”异常，需要的字节数等于我尝试插入的文件的大小。
该服务器是一个虚拟服务器，分配了 4GB 的空间，并且没有其他可能干扰的运行。
为什么我会收到较大文件的内存不足错误，而不是较小的文件？ 这个文件大小限制来自哪里？
我在下面包含了我的配置文件：
[client]
port = 3306
socket …为什么要使用 mysqldump 来重新填充表而不是加载数据文件？
这是我的问题的背景故事。我们有一个表的分区不正确。它应该按 PK 划分为 10M 行块。在 90M => 100M 之后，它开始被分区为 100M 行块（100M=>200M 等）。
最近的分区之间有 135M 行，我们决定是时候花一些停机时间来解决这个混乱的问题了。
游戏计划基本上是：
1) mysqldump >= 100M
2) 删除分区 >= 100M
3）创建所需的分区范围
4）通过mysqldump文件读取
这些转储以 10M 块的形式完成，因此我们可以同时重新加载到已关闭的主服务器和从服务器中，并在两者之间进行一些健全性检查，这样我们就不会在意识到自己被搞砸之前走得太远。这是一个仅附加的表，不会发生变化，因此我们能够在真正的停机时间开始之前提前完成历史转储并 scp 到本地副本。因此，我们添加了 --skip-disable-keys，因为我们的 mysql 版本不允许您对每个分区执行此操作，并且不想在每个块之后连续重建，因此这可能与性能差异有关正要布置呢
之前的一些基准测试给我们留下了估计 90 分钟的停机时间。我们错了；mysqldump 重新加载的时间比预期长约 3-4 倍。
我们有一些时间闲逛。应急计划的一部分是在主分区和其他所有分区都重建之前不要丢弃其中一个从分区，“以防万一”。在重建过程中，我们决定进行一个测试，从未触及的从属设备中为我们尚未到达的某些段选择 * 到输出文件中，然后重新加载这些数据文件。
我们制作了转储，对其进行了 gzip 压缩，并将其复制到正在重建过程中的机器上。为了节省一些必须解压缩然后再次读取的开销，我们将其 gzip -dc 放入命名管道中，然后从其中加载。
加载数据方法大约在 4 分钟/块内完成，而不是 mysqldump 重新加载所需的 12-15 分钟。
我知道手册说这对于较大的负载来说可能会更快，但这让我苦苦思索，如果我们的模式已经就位，为什么我们应该使用 mysqldump？
PS 我知道重新组织分区，但发现过去将转储/重新加载到 alteeed 模式中的性能更高。
为什么 MySQL 将 blob 存储在直接表中而不是放在一边，以便如果它需要读取相应的内容，它将读取到一边的内容？本质上，它会创建自己的文件，该文件在文件文件夹类型的体系结构中不受除自身之外的所有内容的影响，以便更容易/更快地写出 blob 链接。