在使用mysqdump導出的sql時进鸠，1G文件大約導入了20分鐘稠曼，需要頻繁測試，這個不能忍客年，查詢后得到以下優(yōu)化方法霞幅，基本在2分鐘左右漠吻。
導出文件太慢
mysqldump -uxxxx -pxxxx -e --max_allowed_packet=1048576 --net_buffer_length=16384 > backup.sql
說明：
-e 生成insert語句時，使用多行插入的模式司恳，這個對大數(shù)據(jù)性能影響非常大
max_allowed_packet和net_buffer_length是說同行緩存區(qū)的大小途乃，這個值不能比服務器的大，服務器上這樣查看
mysql> show variables like 'max_allowed_packet';
+--------------------+----------+
| Variable_name | Value |
+--------------------+----------+
| max_allowed_packet | 16777216 |
+--------------------+----------+
1 row in set (0.06 sec)
mysql> show variables like 'net_buffer_length';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| net_buffer_length | 16384 |
+-------------------+-------+
1 row in set (0.00 sec)
導出數(shù)據(jù)時出現(xiàn)can’t opne file ‘xx.frm’ (errno:24)錯誤
一開始以為是被鎖了扔傅，后來發(fā)現(xiàn)lock列表是空的耍共，重啟服務后沒有其他連接也不行，后來得知是一個叫open_files_limit的設(shè)置的問題猎塞。
open_files_limit的系統(tǒng)默認值為max_connections*5 或 max_connections + table_cache*2试读。
如果open_files_limit設(shè)置過小，造成打開的文件過多荠耽，就會出現(xiàn)錯誤’xxx.frm’無法打開钩骇。
解決方案：命令行修改global open_files_limit比要導出的表數(shù)量多即可，修改配置文件后重啟也行骇塘。
導入mysql數(shù)據(jù)太慢
- 確保導入的SQL頭部有如下設(shè)置
SET FOREIGN_KEY_CHECKS=0;
SET AUTO_COMMIT=0;
- mysql導入的參數(shù)設(shè)置max_allowed_packet大一些
mysql -uxxxx -pxxxx database --default-character-set=utf8 --max_allowed_packet=256M < backup.sql
