所以我做了一个相当大的数据库的mysqldump ，我正在尝试使用以下命令恢复它：
mysql db_test < db_test.sql
但看起来今年年底还不会结束。 现在一个小时左右还在“恢复”。 做备份需要大约10分钟，所以我担心有什么不好的事情发生。
至今：
mysqld正在消耗我的cpu（有时高达80％）。 我可以看到创build的数据库，并填充了大量的表（不是所有的东西）。 另外，当我执行use db_test; ，我收到以下消息：
阅读表格信息以完成表格和列名称您可以closures此function以使用-A更快地启动
df -h返回与以前相同的可用空间。 所以我想这不是在磁盘上做任何事情。 这里奇怪的是，当检查top ，我发现kworker有时消耗高达100％的CPU，这不应该是发生
任何想法或任何我可以做什么来看看发生了什么？
听起来底层磁盘很忙。 恢复大型数据库的问题是，每个（组）INSERT都需要刷新/同步操作，这对于机械磁盘（7200 RPM磁盘约为100 IOPS）非常缓慢。
为了加速恢复，你必须临时指示MySQL / MariaDB 不要发出刷新/同步。 为此，请中断恢复并使用以下两行编辑/etc/my.ini ：
innodb_flush_method=nosync innodb_flush_log_at_trx_commit=2 然后重新启动MariaDB并重试恢复。 事情现在要快得多。
恢复之后， 删除数据库的上面的行将有一个短暂和糟糕的生活：刷新/同步存在非常重要的原因。 尽pipe将它们closures以进行恢复是可以接受的，但生产数据库不应该在没有它们的情况下运行。
如果您的底层存储是普通的旧磁盘，对于25GB的磁盘MySQL数据库，这对于经历长达数小时的还原是非常正常的，特别是对于一些结构严谨的数据库（大量的元组，索引等）。
为了开始压缩你的转储，这节省了大量的I / O，并且caching内存的压力更小：
mysqldump foo |gzip >foo.sql.gz zcat foo.sql.gz |mysql foo
在你的情况下，因为你已经做了mysqldump：
gzip db_test.sql zcat db_test.sql.gz |mysql db_test
除了系统性能（存储，RAM等）外，MySQL设置可能会产生巨大的影响。 但是，这是一个完整的专业知识，没有什么比通过ServerFault的问题可以处理…