Назад | Перейти на главную страницу

Размер индекса MYI меньше на подчиненном сервере

Я недавно переделал огромное MyISAM таблицу (80 миллионов записей), добавив новое значение в поле перечисления. После этого я проверил состояние таблицы на двух подчиненных серверах, которые используются для репликации главного сервера. Я заметил это 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. Загрузка данных в некотором порядке приводит к однобокому распределению ключей в индексах BTREE. В некоторых случаях все узлы могут быть фрагментированы до 45%.

ПРИМЕР: Если у вас есть двоичное дерево (худшее BTREE), загруженное по порядку, вы получите двоичное дерево, наклоненное до упора вправо, которое должно выглядеть как связанный список с отрицательным наклоном.

Однажды я упомянул об этом безумном явлении в своих сообщениях администратора базы данных на StackExchange.

Aug 03, 2011 : Когда мне следует перестраивать индексы?
Jun 28, 2012 : Преимущества BTREE в MySQL
Oct 26, 2012 : Насколько плохо innodb фрагментируется перед лицом некорректных вставок?

Запуск REPAIR TABLE в клиенте mysql, запущенном myisamchk -r или перезагрузка mysqldump MyISAM всегда должна создавать меньший индексный файл MyISAM.