为什么导入 12 GB .sql 文件需要超过 36 小时？

Question

我已经等了 36 个小时，等待一个 12 GB 的 .sql 文件通过一个简单的type site.sql | mysql命令导入。我可以看到ibdata1它仍在增长，目前接近 40 GB。

考虑到触发器和存储过程在 .sql 的末尾，我只认为 MySQL 应该添加数据和关键索引。

site.sql 是使用此命令从另一台服务器生成的：

mysqldump -R -e --databases site --add-drop-database --add-create-database --add-drop-table -C --single-transaction --triggers

什么要花这么长时间？

Answer 1

尝试这个：

$ ps -ef|grep [m]ysql

然后确定进程ID

$ strace -cp <pid>

再等 10 秒或一分钟^C。这将告诉您进程在哪里花费时间，例如，如果您看到read并write控制它，它可能只是在等待磁盘。

+1 因为我刚刚学会了一个新命令（strace）：P 编辑：废话，默认情况下在我的 mac 上不可用。 (4认同)
Strace 是 Linux - Solaris equiv 是桁架。Dtrace 在 Mac 上可用。 (3认同)
这是一个很棒的工具，还有 gdb。我不再告诉人们他们的应用程序挂了；我确切地告诉他们它卡在什么或在旋转什么，或者从核心告诉他们代码行和源文件的名称。更强大的是 dtrace。 (2认同)

Answer 2

你有带主键的 InnoDB 表吗

这些情况中的任何一个都可能导致索引中的大型 BTREE 节点在每个 BTREE 节点中只有很少的叶子。主键中的集群键也附加到非集群键中的每个非唯一键条目。

另一个考虑：InnoDB 数据页的总和是否明显少于 InnoDB 索引页？

您可以通过此查询（以 MB 为单位）发现这一点：

SELECT SUM(data_length)/POWER(1024,2) InnoDBData,
SUM(index_length)/POWER(1024,2) InnoDBIndexes
FROM information_schema.tables WHERE engine='InnoDB';

附加考虑：您是否在加载的数据库服务器中启用了二进制日志记录？如果是，请在您加载的服务器上执行此操作：

mysql -h... -u... -p... -A -e"SET sql_log_bin=0; source site.sql"

我希望这有帮助！！！

Answer 3

您确定您正在读取的表没有触发器、索引和约束吗？你在什么硬件和操作系统上运行？你的存储是如何配置的？

我更熟悉 oracle，但在没有触发器、索引和约束的表上导入 12G 应该很容易达到 200GB/h。一个单一的触发器可以使过程变成蜗牛，这取决于触发器的作用......

我希望这有帮助