MySQL alter table啟用密鑰的速度不如承諾的那么快

Question

所以我有一個大表，有超過20億條記錄和5個多列密鑰。

我可以使用兩種方法插入數據：

方法1

load data infile ...;

方法2

alter table disable keys;
load data infile ...;
alter table enable keys;

如果我從空表開始，對於20億條記錄，方法1需要大約60小時（估計，可能更多），而方法2需要12小時來插入數據，3小時重新創建密鑰。 到現在為止還挺好。

但是，如果我已經擁有了20億條記錄，並嘗試再插入500萬條記錄，則方法1需要大約3個小時，而方法2需要30分鍾插入數據，並且需要7個小時才能重新創建密鑰。 我確認在整個密鑰重新生成期間，它Repair by sorting使用了Repair by sorting ，所以它不像是Repair with keycache重新Repair with keycache 。

我想知道為什么會這樣。 MySQL聲稱禁用密鑰非常適合插入批量數據，但這顯然取決於上下文。 如果要從頭開始重新生成所有鍵，為什么不需要大約3個小時，就像我開始使用空表一樣？ 或者如果它逐個插入密鑰，為什么不花費大約3個小時，這是方法1所花費的？

歡迎評論

Answer 1

所花費的時間可能會有很大差異。

http://www.mysqlperformanceblog.com/2007/07/05/working-with-large-data-sets-in-mysql/

Answer 2

如果您正在處理數十億條記錄，並使用MySQL 5.1或更高版本，那么您可能會發現分區將有利於提高性能......在分區表中處理索引時，索引也會被分區; 並且因為每個索引僅針對總數據的分區/子集構建，所以重建的分類開銷應該顯着減少。

Answer 3

“沒有那么快的承諾” -呃，你有500萬點的記錄，當然這將需要更長的時間比插入20條記錄。

• 使用第一種方法，它會在每行插入時稍微更改索引，因此它們始終與數據一致。
• 使用第二種方法，它是通過對整個表 （2005000000行） 進行排序來重建索引 - 這意味着它會來回移動大量現有索引數據（磁盤速度很可能會成為這里的瓶頸），這取決於1）現有數據量，2）新數據量。
• 您可以在第二次插入之前使用方法3： drop keys （這可能還需要一些時間）並在之后重新創建它們。 我懷疑時間將類似於在初始插入后重新創建鍵

您描述的速度非常合理恕我直言 - 只需使用最快的方法。