從伺服器上 MYI 索引的大小更小

我最近MyISAM通過在列舉欄位中添加一個新值來更改一個巨大的表（8000 萬個條目）。完成此操作後，我檢查了用於複製主伺服器的 2 個從屬伺服器上的表的執行狀況。我注意到MYI其中一台從伺服器上的文件要小得多。我已經修復了表，myisamchk但是REPAIR索引的大小沒有改變。

請參閱下面的myisamchk -dvv“密鑰文件長度”在這 3 個伺服器上執行返回的結果：

Master Server
Auto increment key:              1  Last value:              80098340
Data records:             79375556  Deleted blocks:                 0
Datafile parts:           79375556  Deleted data:                   0
Datafile pointer (bytes):        6  Keyfile pointer (bytes):        6
Datafile length:        9635014668  **Keyfile length:       18945252352**
Max datafile length: 281474976710654  Max keyfile length: 288230376151710719
Recordlength:                 1110

Slave Server 1
Auto increment key:              1  Last value:              80097611
Data records:             79374828  Deleted blocks:                 0
Datafile parts:           79394418  Deleted data:                   0
Datafile pointer (bytes):        6  Keyfile pointer (bytes):        6
Datafile length:        9635788652  **Keyfile length:       18024821760**
Max datafile length: 281474976710654  Max keyfile length: 288230376151710719
Recordlength:                 1110


Slave Server 2 - Here the size of Keyfile is much smaller
Auto increment key:              1  Last value:              80098312
Data records:             79375002  Deleted blocks:                 0
Datafile parts:           79375002  Deleted data:                   0
Datafile pointer (bytes):        6  Keyfile pointer (bytes):        6
Datafile length:        9634942908  **Keyfile length:       11092404224**
Max datafile length: 281474976710654  Max keyfile length: 288230376151710719

什麼可能導致如此顯著的差異？

如果您對 MyISAM 進行修復，它應該會減小MYI. 為什麼 ？

當 mysqldump 創建並載入 MyISAM 表時，請考慮以下機械步驟mytable：

CREATE TABLE mytable ...
LOCK TABLE mytable ...
ALTER TABLE mytable DISABLE KEYS; (shuts off updates to non-unique indexes)
INSERT INTO ...
INSERT INTO ...
.
.
.
ALTER TABLE mytable ENABLE KEYS; (rebuild all indexes)
UNLOCK TABLES;

期間ALTER TABLE ... ENABLE KEYS，你跑SHOW PROCESSLIST;

你會看到那個過程的資訊說Repair by sorting

完成後，您應該擁有一個 MYI，其中 95% 的 BTREE 節點已滿。

為什麼修復後會消失這麼多空間？看看相反的情況。

您正在某個 auto_increment id 上按數字順序載入表格。以某種有序方式載入數據會在 BTREE 索引中產生不平衡的密鑰分佈。在某些情況下，所有節點的碎片率最高可達 45%。

範例：如果您按順序載入了一棵二叉樹（最差的 BTREE），您會得到一棵一直向右傾斜的二叉樹，它應該看起來像一個具有負斜率的鍊錶。

我曾經在我的 DBA StackExchange 文章中提到過這種瘋狂的現象

• Aug 03, 2011:我應該什麼時候重建索引？
• Jun 28, 2012: BTREE 在 MySQL 中的好處
• Oct 26, 2012:面對亂序的插入，innodb 的碎片有多嚴重？

REPAIR TABLE在 mysql 客戶端中執行，執行或myisamchk -r重新載入 MyISAM 的 mysqldump 應該始終生成較小的 MyISAM 索引文件。

引用自：https://serverfault.com/questions/661962