提高mysql导入速度

Posted

技术标签:

【中文标题】提高mysql导入速度【英文标题】：improve speed of mysql import 【发布时间】：2015-06-21 00:42:29 【问题描述】：

我有22GB 的大型数据库。我曾经使用 gzip 格式的mysqldump 命令进行备份。

当我提取 gz 文件时，它会生成 .sql 文件 16.2GB

当我尝试在本地服务器中导入数据库时​​，导入大约需要 48 小时。有没有办法提高导入过程的速度？

我也想知道是否需要进行任何硬件更改以提高性能。

当前系统配置

 Processor: 4th Gen i5
 RAM: 8GB

#update

my.cnf如下

#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
# 
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html

# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port        = 3306
socket      = /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket      = /var/run/mysqld/mysqld.sock
nice        = 0

[mysqld]
#
# * Basic Settings
#
user        = mysql
pid-file    = /var/run/mysqld/mysqld.pid
socket      = /var/run/mysqld/mysqld.sock
port        = 3306
basedir     = /usr
datadir     = /var/lib/mysql
tmpdir      = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address        = 127.0.0.1
#
# * Fine Tuning
#
key_buffer      = 16M
max_allowed_packet  = 512M
thread_stack        = 192K
thread_cache_size       = 8
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover         = BACKUP
#max_connections        = 100
#table_cache            = 64
#thread_concurrency     = 10
#
# * Query Cache Configuration
#
query_cache_limit   = 4M
query_cache_size        = 512M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file        = /var/log/mysql/mysql.log
#general_log             = 1
#
# Error log - should be very few entries.
#
log_error = /var/log/mysql/error.log
#
# Here you can see queries with especially long duration
#log_slow_queries   = /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id      = 1
#log_bin            = /var/log/mysql/mysql-bin.log
expire_logs_days    = 10
max_binlog_size         = 100M
#binlog_do_db       = include_database_name
#binlog_ignore_db   = include_database_name
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem



[mysqldump]
quick
quote-names
max_allowed_packet  = 512M

[mysql]
#no-auto-rehash # faster start of mysql but no tab completition

[isamchk]
key_buffer      = 512M

#
# * IMPORTANT: Additional settings that can override those from this file!
#   The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/

它正在上传 3 天，现在已导入 9.9 GB。数据库有 MyISAM 和 InnoDB 表。我可以做些什么来提高导入性能？

我尝试使用 mysqldump 以 gz 格式分别导出每个表，并通过执行以下代码的 php 脚本导入每个表

$dir="./";
$files = scandir($dir, 1);
array_pop($files);
array_pop($files);
$tablecount=0;
foreach($files as $file)
    $tablecount++;
    echo $tablecount."     ";

    echo $file."\n";
    $command="gunzip < ".$file." | mysql -u root -pubuntu cms";

    echo exec($command);

【问题讨论】：

你能接受mysql服务器宕机几秒钟吗？如果可以的话，直接备份mysql数据库文件，恢复的时候直接复制回来。这两个操作都需要将 mysql 服务器脱机。这是一种不安全但有效的方式。 你有几张桌子？ 你可以添加更多关于问题的信息——是瓶颈CPU还是磁盘，是导致导入缓慢的特定表；如果是这样，表的结构是什么，有多少行等等。 @Alex 我有 204 张桌子 我们有一些大表（10GB），对于 MySQL 来说，导入/导出实在是太多了。帮助是将大型日志表移动到 MongoDB。我知道这不会解决你的问题，但有一天你可能需要做出决定。 【参考方案1】：

[Vinbot's answer above][1] 中使用LOAD DATA INFILE 描述的方法是我每天在本地桌面上引入大约 1 Gb 用于分析过程的方法（我没有 DBA 或 CREATE TABLErights on服务器，但我在本地 mySQL 上执行）。

mySQL 8.0.17 中引入的一项新功能，即[mySQL Parallel Table Import Utility][2]，将其提升到了一个新的水平。

在配备 SATA SSD 的 Intel Core I7-6820HQ 上，以前需要大约 15 分钟（大约 1 Gb）的 CSV 表导入现在需要 5:30。当我添加一个 nVME M.2 1Tb WD Black 驱动器（为旧桌面购买但证明不兼容）并将 mySQL 安装移动到该驱动器时，时间下降到 4 分 15 秒。

在运行该实用程序之前，我在表定义中定义了大部分索引。如果没有索引，加载速度会更快，但加载后索引最终会花费更多的总时间。这是有道理的，因为 Parallel Loader 的多核功能扩展到索引创建。

我还在并行加载程序实用程序脚本中ALTER INSTANCE DISABLE INNODB REDO_LOG（引入 8.0.21）。注意警告不要在完成批量加载后将其关闭。我没有重新启用并以损坏的实例结束（不仅仅是表，而是整个实例）。我总是关闭双写缓冲。

CPU 监视器显示该实用程序充分利用了所有 8 个内核。

完成并行加载程序后，它会返回到单线程 mySQL（用于我的线性分析任务集，而不是多用户）。新的 nVME 将时间缩短了 10% 左右。该实用程序每天为我节省几分钟。

该实用程序允许您管理缓冲区大小和线程数。我匹配了我的 CPU (8) 中的物理内核数量，这似乎是最佳的。 （我最初来这个线程是为了寻找有关配置并行加载程序的优化技巧）。 [1]：https://***.com/a/29922299/5839677 [2]：https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-parallel-table.html

【讨论】：

【参考方案2】：

以上述方式进行转储和恢复意味着 MySQL 必须在导入数据时完全重建索​​引。它还必须每次解析数据。

如果你能以 MySQL 已经理解的格式复制数据文件，效率会高得多。这样做的一个好方法是使用来自 Percona 的innobackupex

（开源并作为XtraBackup 的一部分分发，可从here 下载）。

这将拍摄 MyISAM 表的快照，对于 InnoDB 表，它将复制底层文件，然后针对它们重放事务日志以确保一致的状态。它可以从实时服务器上执行此操作而无需停机（我不知道这是否是您的要求？）

我建议您阅读文档，但要以最简单的形式进行备份：

$ innobackupex --user=DBUSER --password=DBUSERPASS /path/to/BACKUP-DIR/
$ innobackupex --apply-log /path/to/BACKUP-DIR/

如果数据在同一台机器上，那么 innobackupex 甚至还有一个简单的恢复命令：

$ innobackupex --copy-back /path/to/BACKUP-DIR

还有更多的选项和不同的实际备份方式，所以我真的建议您在开始之前仔细阅读文档。

作为速度参考，我们的慢速测试服务器大约 600 IOPS 可以使用这种方法在大约 4 小时内恢复 500 GB 的备份。

最后：您提到了加快导入速度的方法。这主要取决于瓶颈是什么。通常，导入操作受 I/O 限制（您可以通过检查 io 等待来测试这一点），加快速度的方法是使用更快的磁盘吞吐量 - 或者更快的磁盘本身，或者同时使用更多的磁盘。

【讨论】：

【参考方案3】：

我不确定它是否适合您，但最好的方法是 Tata 和 AndySavage 已经说过：从生产服务器获取数据文件的快照，然后将它们安装到本地机器上通过使用 Percona 的 innobackupex。它将以一致的方式备份 InnoDb 表并在 MyISAM 表上执行写锁定。

在生产机器上准备完整备份：

http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/preparing_a_backup_ibk.html

将备份的文件复制（或在进行备份时通过 SSH 传输 - 更多信息 here）到您的本地计算机并恢复它们：

恢复备份：

http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/restoring_a_backup_ibk.html

您可以在此处找到 innobackupex 的完整文档：http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/innobackupex_script.html

恢复时间将比读取 SQL 转储快得多。

【讨论】：

【参考方案4】：

我不得不处理同样的问题。我发现使用 mysqldump 输出到 CSV 文件（像这样）：

mysqldump -u [username] -p -t -T/path/to/db/directory [database] --fields-enclosed-by=\" --fields-terminated-by=,

然后使用 mysql 客户端中的 LOAD DATA INFILE 查询导入该数据（如下所示）：

LOAD DATA FROM INFILE /path/to/db/directory/table.csv INTO TABLE FIELDS TERMINATED BY ',';

比仅执行包含数据的 SQL 查询快一个数量级。当然，它也依赖于已经创建的表（并且是空的）。

您当然也可以通过先导出然后导入空架构来做到这一点。

【讨论】：

将-T 选项与 msyqldump 一起使用的一个重要警告是，这仅在 mysqldump 与 mysqld 服务器在同一台机器上运行时才有效。【参考方案5】：

确保将“ma​​x_allowed_pa​​cket”变量增加到足够大的大小。如果您有大量文本数据，这将非常有帮助。使用高性能硬件肯定会提高导入数据的速度。

mysql --max_allowed_packet=256M -u root -p < "database-file.sql"

【讨论】：

max_allowed_pa​​cket = 512M 在配置中，因此将其设为 256M 实际上会减小其大小。【参考方案6】：

方式一：按照 fakedrake 的建议禁用外键。

设置自动提交 = 0; SET FOREIGN_KEY_CHECKS=0

方式 2：使用 BigDump，它将分块您的 mysqldump 文件，然后将其导入。 http://www.ozerov.de/bigdump/usage/

问题：你说你在上传？你是如何导入你的转储的？不是直接从服务器/命令行？

【讨论】：

【参考方案7】：

获得更多 RAM、获得更快的处理器、获得更快写入速度的 SSD。批量插入，使它们比一堆单独的插入运行得更快。这是一个巨大的文件，需要时间。

【讨论】：

【参考方案8】：

有很多参数缺失，要全面了解问题的原因。如：

    MySQL 版本 磁盘类型和速度 在启动 MySQL 服务器之前释放服务器上的内存 mysqldump 之前和当时的 iostat 输出。 首先用于创建转储文件的参数是什么。

还有更多。

所以我会尝试猜测您的问题出在磁盘上，因为我有 150 个 MySQL 实例，我在其中一个上管理 3TB 数据，通常磁盘是问题

现在解决方法：

首先 - 您的 MySQL 没有配置为最佳性能。

您可以在 Percona 博客文章中了解要配置的最重要设置： http://www.percona.com/blog/2014/01/28/10-mysql-settings-to-tune-after-installation/

特别检查参数：

innodb_buffer_pool_size 
innodb_flush_log_at_trx_commit
innodb_flush_method

如果您的问题是磁盘 - 从同一驱动器读取文件 - 会使问题变得更糟。

如果您的 MySQL 服务器因为没有足够的可用 RAM 而开始交换 - 您的问题会变得更大。

您需要在还原过程之前和还原过程中对您的计算机运行诊断程序以找出答案。

另外，我可以建议你使用另一种技术来执行重建任务，它比 mysqldump 工作得更快。

这是 Percona Xtrabackup - http://www.percona.com/doc/percona-xtrabackup/2.2/

您将需要使用它创建备份，并从中恢复，或者使用流选项直接从正在运行的服务器重建。

此外，从 5.5 开始的 MySQL 版本 - InnoDB 的执行速度比 MyISAM 快。考虑将所有表都更改为它。

【讨论】：

将表更改为 MyISAM 到 InnoDB 会影响任何关系吗？或对我的数据库有任何损坏？使用 MyISAM 比使用 InnoDB 有什么特别的优势吗？ 如果你问任何一位 MySQL 专家——他们都会说——不。今天使用 MyISAM 与 InnoDB 相比没有任何优势。但是你需要验证使用你的表的代码，并确保它不依赖于 MyISAM 执行的表锁 标准 mysqldump 和 import 最大的问题并不是硬盘是瓶颈，最大的问题是当你这样做时，你实际上是在将所有数据再次插入到一个表中，而不是而不是简单地复制数据结构。因此，您必须重新创建结构。这是一个主要的软件限制，慢速磁盘会加剧这种限制。在备份方面，MyISAM 比 Innodb 有一个非常实际的优势：您可以简单地锁定和刷新表并使用 cp 或 scp 复制数据，它工作正常（记得 chown mysql:mysql 文件）。 @ChrisSeline - 你可以对 InnoDB 表做同样的事情，但是当你这样做时 - 你的数据库将无法正常工作。不要尝试以这种方式从生产数据库中备份 1TB 的数据。 使用 InnoDB 执行此操作要复杂得多。我使用 scp 成功地复制了带有 InnoDB 表的整个数据库，但我从来没有成功使用单个表。而且您仍然可以备份生产数据，只是在执行此操作时无法写入表:)。无论如何，我确信这就是 Percona 工具存在的原因，因为它是一件让人头疼的事情！【参考方案9】：

你可以做的一件事是

SET AUTOCOMMIT = 0; SET FOREIGN_KEY_CHECKS=0

你也可以玩转价值观

innodb_buffer_pool_size
innodb_additional_mem_pool_size
innodb_flush_method

在my.cnf 中为您提供帮助，但通常您也应该查看rest of innodb parameters 以了解最适合您的方式。

这是我过去遇到的一个问题，我觉得我没有完全解决，但我希望我从一开始就为自己指明了这个方向。本来可以为自己节省不少时间。

【讨论】：

目前正在进行正常导入。完成后让我试试这个 在 my.cnf 中设置 innodb_buffe_pool_size 不会启动 mysql 服务器 @DharanBro 那是因为你拼错了。

以上是关于提高mysql导入速度的主要内容，如果未能解决你的问题，请参考以下文章

Navicat for MySQL导入数据库时特别慢，怎么样能提高速度？

如何在 SQL Workbench/J 上提高导入速度

如何提高mysql查询速度

PostgresSQL使用Copy命令能大大提高数据导入速度

Elasticsearch：如何提高 Elasticsearch 数据摄入速度

Elasticsearch：如何提高 Elasticsearch 数据摄入速度