mysqldump 与 LOAD DATA INFILE

Question

为什么要使用 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 模式中的性能更高。

Answer 1

如果您已经有一个模式，则应该使用 mysqldump 选项创建数据转储以仅在插入中执行

mysqldump -h... -u... -p... --no-create-info --databases ... > MySQLData.sql

您还应该确保提高所有数据库服务器上的bulk_insert_buffer_size（默认为8M）以适应大型扩展插入。如果加载非空表，这也将有助于 LOAD DATA INFILE。

您还必须调整max_allowed_pa​​cket（默认值为 1M）。

对于初学者来说，请尝试以下设置：

[mysqld]
max_allowed_packet=256M
bulk_insert_buffer_size=256M

更新 2011-10-11 06:53 美国东部时间

无论硬件有多强大，分配了多少 RAM，操作系统调整得有多好，以及 MySQL 的版本有多新，MySQL 只会按照其配置运行。

示例：如果您有一个可容纳 10,000 加仑水的游泳池，您有一辆可容纳 10,000 加仑水的卡车，而卡车上的软管只有吸管那么大，您只能将这么多的水推过游泳池。稻草填满池子。获得更大的卡车或更快的水泵根本不会改善情况。您必须将软管更换为更大的软管以容纳更多的水，从而提高吞吐量。

同样，MySQL 5.5 开箱即用并没有经过完全调优。

示例#1： MySQL 5.5 带有半同步复制。默认情况下，它是禁用的。您必须执行启动 mysql、在主从模块上运行 INSTALL PLUGIN、关闭 mysql、为 semisych 功能添加计时和激活选项到 my.cnf 的两步过程，然后第二次启动 mysql。只有这样，半同步复制才会起作用。

示例 #2：批量插入缓冲区默认为 8M。由于任何特定硬件或软件的存在，批量插入缓冲区不会增长。它保持 8M，直到您增加它。可以通过将其添加到 my.cnf 并重新启动 mysql 或SET bulk_insert_buffer_size = 268435456;在会话中运行将其设置为 256M，然后在同一会话中加载 mysqldump 来增加它。

示例 #3： MySQL 5.5 完全能够使用多个 CPU。默认情况下，启用多个 CPU 的功能处于禁用状态。它们需要调整，因为尽管 MySQL 5.5 已支持多核，但 MySQL 5.5 的多线程程度仅取决于您的配置。

结论：您必须配置 MySQL 以认识到它具有强大的硬件、更多的 RAM 和可供使用的协作操作系统。