Tamanho do índice MYI menor no servidor escravo

Question

Alterei recentemente uma grande tabela MyISAM (80 milhões de entradas) adicionando um novo valor em um campo enum. Depois que fiz isso, verifiquei a integridade da tabela em dois servidores escravos que são usados para replicar o servidor mestre. Eu notei que o arquivo MYI é muito menor em um dos servidores escravos. Eu consertei a tabela com myisamchk e REPAIR , mas o tamanho do índice não foi alterado.

Por favor, veja abaixo os resultados retornados executando myisamchk -dvv nestes 3 servidores para "Tamanho do arquivo de chaves":

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

O que poderia causar uma diferença tão significativa?

    

Answer 1

Se você executou um reparo no MyISAM, ele deve reduzir o tamanho do MYI . Por quê?

Quando um mysqldump cria e carrega uma tabela MyISAM, pense nas etapas mecânicas para fazer 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;

Durante o ALTER TABLE ... ENABLE KEYS , você executa SHOW PROCESSLIST;

Você verá as informações desse processo dizendo Repair by sorting

Quando terminar, você deve ter um MYI com 95% de mais nós BTTE preenchidos até a capacidade.

Por que tanto espaço desaparece quando você conserta? Olhe para o caso oposto.

Você está carregando uma tabela em ordem numérica em algum ID de auto_increment. Carregar dados de alguma forma ordenada produz uma distribuição de chaves desequilibrada nos índices BTREE. Em alguns casos, todos os nós podem ter até 45% de fragmentação.

EXEMPLO: Se você tiver uma árvore binária (a pior BTREE) carregada em ordem, você terá uma árvore binária inclinada para a direita, que deve se parecer com uma lista encadeada com uma inclinação negativa.

Certa vez mencionei esse fenômeno louco em meus posts do DBA StackExchange

• Aug 03, 2011 : Quando devo recriar os índices?
• Jun 28, 2012 : Benefícios do BTREE no MySQL
• Oct 26, 2012 : O quanto o innodb se fragmenta diante de inserções um pouco fora de ordem?

A execução de um REPAIR TABLE no cliente mysql, executando myisamchk -r ou recarregando um mysqldump de um MyISAM, deverá produzir sempre um arquivo de índice MyISAM menor.