【问题标题】:Import .sql file using multiple threads?使用多个线程导入 .sql 文件?
【发布时间】:2014-08-06 07:06:02
【问题描述】:

我有一个巨大的 SQL 文件(大约 69GB)。我想将它导入我的本地数据库。所有表都是基于 InnoDB 引擎的。


我已经尝试过标准的导入方式

mysql -u*** -p**** db_name < dump.sql

source /location/dump.sql

但是这些花费了太多时间。


在 SQL 或 Python 中有没有什么方法可以创建对应 diff 表的多个线程并导入它们?有没有其他方法可以加快这个过程?

【问题讨论】:

    标签: python mysql mysqldump


    【解决方案1】:

    您正在进行的恢复:

        mysql -u*** -p**** db_name < dump.sql
    

    这将是最快的方式 - 在 python 中,您必须进行多次插入,这会慢很多。

    【讨论】:

    • 我的想法是以某种方式从转储中提取 diff 表,然后使用 python 中的多线程模块运行单独的转储查询,但在 diff sql 表中分离它是一个问题
    【解决方案2】:

    您可能会分析转储文件并尝试将插入到不同表中的内容发送到不同的命令流,但我怀疑这是否值得。考虑到读取和重定向会在您的处理链中增加一个步骤,并且所有 69 GB 都必须通过此步骤。

    您的主要性能限制是所有这些数据形成一个流,因此所有插入事务都是按顺序完成的。通过告诉数据库服务器不要立即将所有提交条目写入日志(= 每个事务 1 次同步写入),您可能会获得一些加速。最简单的方法是
    mysql -u*** -p*** 数据库名
    设置会话 innodb_flush_log_at_trx_commit = 0;
    source /location/dump.sql

    但是,这并不会减少要写入的数据总量,因此加速会受到限制。

    【讨论】:

    • 是的,我同意你的观点,但那是一个生产数据库,我什至没有设置日志变量的权限,所以它对我没有用
    • 您不会在全局范围内设置变量,您只会为加载转储的会话执行此操作。 AFAIK,没有什么可以阻止您在命令流中执行此操作。一旦该会话终止,该设置就没有实际意义。当然,我们通常希望记录提交(DBMS 术语中的“稳定存储”),但对于现有文件,这并不重要,因为您可以在崩溃时重复该运行。
    猜你喜欢
    • 2015-11-26
    • 1970-01-01
    • 2015-03-29
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-03-08
    • 1970-01-01
    相关资源
    最近更新 更多