bitsCN.com
日常工作中经常会有需要从mysqldump导出的备份文件恢复数据库的情况，相比物理备份恢复这种方式在恢复时间上往往显得力不从心。
本文就总结了几个对于逻辑备份恢复有加速作用的参数和操作
注意：我们的大前提是，恢复的目标数据库在恢复完成前，没有对外部提供服务
1. 参数调整
log-bin=OFF恢复时开启二进制日志显然是无意义的，增加了不必要的IO。因此关闭该选项
sync_binlog=0
如果关闭了二进制日志，则这个选项不调整。
但如果因为特殊原因不能关闭二进制日志时，可以考虑减少binlog的fsync来减少磁盘IO压力。
Innodb_buffer_pool_size 尽可能大
尽可能大的配置Innodb_buffer_pool_size 来保证更多的脏页能够存在于BP中，增大潜在的写入合并的可能性，从而减少了磁盘的IO。
Innodb_logfile_size=1G 或更大
增大redolog的体积可以推迟blocking checkpoint发生的时间，也一定程度缓解adaptive flush的刷写频率。
调整这个参数对于恢复表体积远大于Innodb Buffer Size时非常有用。
Innodb_doublewrite=OFF
由于不存在宕机风险（即使宕机，也就是重新再恢复一次），所以doublewrite也可以不需要了。
Innodb_flush_log_at_trx_commit=0
同上，由于不存在宕机风险，无需那么卖力的刷写redo log。
Innodb_flush_neighbors=1
由于逻辑导入更多的是顺序写入，打开flush neighbor以后不单能把IO pattern更贴近顺序。同时，innodb的内部逻辑也会把多个page合并成一次IO进行提交，刷写性能更高。
2. 其他操作
当然对于逻辑恢复速度影响最大的还是索引的计算。
如果是5.5以后或者percona 5.1以后的版本，建议先建表，导入数据，最后创建索引这样的方式进行恢复。因为这些版本的create index或者alter table对于索引的创建做了优化处理。直接在数据上进行计算生成索引，而不是通过新建一张临时表、插入、替换老表的这种土掉渣的方式创建索引。
bitsCN.com
