MySQL备份的过程使用了bzip2压缩以节省存储空间，正常的恢复过程是
[cc lang='sql']
解压
nohup pbzip2 -d -k -p10 dump_dbcc_20131103.sql.bz2 &
恢复
nohup mysql -uroot < dump_dbcc_20131103.sql &
[/cc]
关于pbzip2请参考帮助，非常给力的并行压缩工具
但是通过解压和dump需要两个过程，而且消耗时间和临时的存储空间
那么我们能否使用管道的方式直接导入呢
[cc lang='sql']nohup pbzip2 -d -k -c dump_dbcc_20131103.sql.bz2 |mysql -uroot -S /u01/mysql/run/mysql.sock -f &[/cc]
测试结果，到备份文件小的情况下有时候可以导入，但当压缩文件非常大的情况下，会报错
[cc lang='sql']ERROR 1064 (42000) at line 218731: You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the
right syntax to use near 'caught [sig=1], quitting...
Terminator thread: premature exit requested - quitti' at line 2 [/cc]
怀疑是否是多线程解压的问题，那么改用单线程解压并管道导入呢，加上进程控制参数 -p
[cc lang='sql']nohup pbzip2 -d -k -c -p1 dump_dbcc_20131103.sql.bz2 | nohup mysql -uroot -S /u01/mysql/run/mysql.sock -f &[/cc]
依旧报上述错误
caught [sig=1], quitting ，去掉nohup，用screen代替。
尝试成功了
screen是个好工具，让进程免受 HUP 信号的影响
简单说：
* CTRL-a d 来暂时断开当前会话
* screen -dmS session name 来建立一个处于断开模式下的会话（并指定其会话名），简单的用screen就ok
* screen -list 来列出所有会话。screen -ls
* screen -r session name 来重新连接指定会话
-------
单进程导入总是很慢的，可以用split将通过管道并行解压的文件拆分，然后用多个MySQL进程并行导入。当然这个是需要做成工具的。
--eof
This work is licensed under a CC A-S 4.0 International License.