恢復MySQL數據庫的工作，但也因爲一直被這個問題困擾，導致進度緩慢。簡單來說，如果我們希望對MySQL restore比較大的數據備份，可能會發生這種情況。對於我來講，需要恢復的庫中有一個表解壓後超過了100GB，而我的服務器是500GB的SSD，想着恢復總大小爲270GB的數據，怎麼都夠了，但實際上發現，影響數據庫restore最重要的問題就是硬盤的空間。
據StackOverflow上這個頁面裏介紹：https://stackoverflow.com/questions/1067367/how-to-avoid-repair-with-keycache
MySQL will use repair by keycache for MyISAM tables whenever the maximum possible size of the tables indexes are greater than the value for the variable myisam_max_sort_file_size.
You can calculate the maximum size of the index by adding up the byte size values for all keys in all the indexes and multiplying that by the number of rows in your table.
簡單估算一下Repair by sorting所需要的硬盤空間，我不太瞭解我需要導入的表的結構，從我這裏來看，即便設置成200GB（100GB的兩倍），還是會發生Repair with keycache。另外，由於我工作在32G內存的機器上，本來想着myisam_sort_buffer_size可以設置更大一些，另外還設置了超過一個repair線程，但是發現，如果MySQL獲取不到這裏面配置的足夠的內存，將立刻轉爲Repair with keycache。所以，對於非常大的表而言，足夠的硬盤空間，比其他因素更能影響restore的速度。
最終是這樣設置的：
myisam_max_sort_file_size = 200G
myisam_sort_buffer_size = 4096M
myisam_repair_threads = 1
Mysql導入大表文件時注意修改參數
set global max_allowed_packet=100000000;
set global net_buffer_length=100000;
SET GLOBAL interactive_timeout=28800000;
SET GLOBAL wait_timeout=28800000;
SET GLOBAL myisam_max_sort_file_size=268435456000;