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

我一直在等待36个小时，以便使用一个简单的type site.sql | mysql命令导入12 GB的.sql文件。我可以看到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

什么要花这么长时间？

mysql mysql-5 mariadb

— 服务器失败
source

mysql占用多少cpu？如果它是一个低值，则可能意味着您受到磁盘限制

— Derek Downey

.sql文件的导入确实不是那么快...转储到tab delim或CSV文件，然后构建空数据库并使用，实际上更快LOAD DATA INFILE。另外，在移动整个数据库时，请参阅我的回答：在服务器之间移动数据库（如果您使用的是同一主要版本）。（特别是如果您必须中止并重新启动）

— 乔

Answers:

尝试这个：

$ ps -ef|grep [m]ysql

然后确定进程ID

$ strace -cp <pid>

留下10秒钟或一分钟^C。这将告诉您该进程在哪里花费时间，例如，如果看到read并write占据主导地位，它可能只是在等待磁盘。

— 盖乌斯
source

+1是因为我刚刚学习了一个新命令（strace）：P编辑：废话，默认情况下在我的Mac上不可用。

— 德里克·唐尼

与gdb一起，它是一个了不起的工具。我不告诉别人他们的应用程序已挂起；我确切地告诉他们它是卡在或旋转的，或者从内核告诉他们代码行和源文件的名称。dtrace甚至更强大。

— Gaius

Strace是Linux-Solaris等同物是truss。Dtrace在Mac上可用。

— Gaius

就是这样现在去阅读它。

— 德里克·唐尼

当心：不错的命令，但请注意，此命令使我的MySQL实例崩溃。不知道为什么。在MySQL崩溃之前，服务器已经几分钟没有响应。

— dabest1 2011年

你有没有带有主键的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';

附加注意事项：正在加载的DB服务器中是否启用了二进制日志记录？如果是这样，请在要加载的服务器上执行以下操作：

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

我希望这有帮助！！！

— 罗兰多·MySQLDBA
source

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

我对oracle更为熟悉，但是在没有触发器，索引和约束的情况下在表上进行12G导入应该轻松达到200GB / h。一个触发器可以使过程变成蜗牛，具体取决于触发器的作用...

我希望这有帮助

— ik_zelf
source