mysql - 导入 MySQL 数据库很慢，但没有明显的瓶颈

Question

我正在将一个 20 GB 的数据库导入我的 MySQL 5.7 服务器。转储是在同一台服务器上进行的。操作系统为Ubuntu 16.04

问题是它运行得非常慢。

这是我的 MySQL 配置:

[mysqld]
#
# * Basic Settings
#
user        = mysql
pid-file    = /var/run/mysqld/mysqld.pid
socket      = /var/run/mysqld/mysqld.sock
port        = 3306
basedir     = /usr
datadir     = /nvme/mysql
tmpdir      = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking

innodb_buffer_pool_size = 18120M
innodb_lock_wait_timeout= 99999999
innodb_change_buffering=all
innodb_flush_log_at_trx_commit=0
innodb_log_file_size=1G
innodb_autoinc_lock_mode=2

#key_buffer     = 4048M
max_allowed_packet  = 1024M
thread_stack        = 256M
thread_cache_size       = 1024
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover-options  = BACKUP
query_cache_limit   = 4M
query_cache_size    = 512M

log_error = /var/log/mysql/error.log
expire_logs_days    = 10
max_binlog_size   = 1G

这是来自另一个文件的 Mysqldump 配置

[mysqldump]
quick
quote-names
max_allowed_packet  = 1024M

这是我用来创建转储的命令

mysqldump --order-by-primary --opt --max-allowed-packet=64M dbName | gzip > dbDump.sql.gz"

还有这个导入它

pv dbDump.sql.gz | { echo "set sql_log_bin=0;SET autocommit=0;SET unique_checks=0;SET foreign_key_checks=0;"; zcat; \
> echo "SET unique_checks=1;SET foreign_key_checks=1;SET autocommit=1;COMMIT;";} | mysql -uuser -ppwd awesomeDb

使用 autocommit=1 导入需要 48 分钟，使用 autocommit=0 需要 53 分钟。

现在是硬件。

I'm running an Intel 4690K on 3.5Ghz , 4 cores
32 gigs of RAM.
The Dump is located on a Samsung 850 SSD.
The Database has a dedicated m.2 NVMe SM961 128 drive. Write speeds in Crystalmark for randomized writes are ~200-300MBps.  

Mysqld 的资源使用情况(由 KSysGuard 报告)

Ram is constantly on 20.5GB  
CPU is 15-19%, so it's not using a whole core. 
The NVMe drive is being written on at 10-40 MiBPS. (had the same speeds on the 850 250GB). It's performing 50-200 read accesses per second 

我尝试了 MySQL 服务器文档中的所有解决方案。尝试添加 set sql_log_bin=0;SET autocommit=0;SET unique_checks=0;SET foreign_key_checks=0;在转储之前。但是数据库仍然需要很长时间才能导入。

我知道从服务器直接复制文件是最快的方法。但我的目标是加快转储导入。

而且我不知道瓶颈在哪里。因为很明显 - 没有什么是最大化的。

编辑于:
DB Schema 是大约 200 个表，有 386 个外键(和 200 个索引)。没有一张表超过 10M 行，最大表的大小为 2.3、2.0、1.3、1.3、0.9 GB。

编辑:
查询缓存在测试期间始终处于禁用状态。此外，今天我导入了一个 12gb 的数据库(相同的数据库，只是更小)。花了 34 分钟。而数据库本身几乎小了两倍。

Answer 1

恢复一个mysqldump文件自然只用一个线程，串行导入数据，一个表接一个表。

我建议使用 mysqldump --tab(带有其他选项)将每个表转储到两个文件中:一个用于模式定义的 .sql 文件和一个用于原始数据的文本文件。

然后，您可以使用 mysqlimport --use-threads=4(使用其他选项来处理所有文件)导入数据文件(在创建所有表之后)，这样您就可以同时加载多个表.

此方法还跳过了所有使用 SQL 进行导入，从而减少了大量的 SQL 解析开销。

您也可以尝试使用 mydumper & myloader ，它们是支持转储和恢复并行操作的开源社区工具。我不知道它目前是否可以作为预构建的二进制文件使用，您可能必须从源代码构建它才能获得最新版本。

最快的恢复解决方案是使用 Percona XtraBackup 进行物理备份.恢复根本不需要导入，您只需将文件放在适当的位置并启动 MySQL 服务器即可。但是导入数据到现有的 MySQL 服务器是不可能的。恢复物理备份需要关闭 MySQL 服务器并覆盖已经存在的所有数据。