Eu tenho esta tabela:
CREATE TABLE `foo` (
`CalculatedResultsId` int NOT NULL,
`Md5Hash` char(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL,
`SectionData` json NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci;
ALTER TABLE `foo`
ADD UNIQUE KEY `CalculatedResultsId` (`CalculatedResultsId`),
ADD UNIQUE KEY `Md5Hash` (`Md5Hash`);
que contém ~ 400 mil linhas e tem ~ 800 MB de tamanho. Esta é a saída do PMA:
Em seguida, excluo 2.454 linhas [< 0,6%], o que produz uma sobrecarga de cerca de 5 MB, que também está documentada no PMA:
A execução OPTIMIZE Tablerepentina dobra o tamanho desta tabela. Verifiquei o tamanho real do arquivo da tabela no diretório e está correto. Realmente dobrou!
Minha pergunta:
Por que, o que está acontecendo? O que aconteceu, qual é a razão, que o tamanho da mesa dobrou?
A única maneira que encontrei de reduzir o tamanho da tabela como era antes é criar uma nova tabela e preenchê-la novamente. Outro fato muito estranho:
Executando este comando para obter a cópia da tabela grande CREATE TABLE foo_new AS SELECT * FROM foo;é executado por 27! minutos para essas 400 mil linhas.
Criando uma tabela vazia e depois copiando com INSERT INTO foo_new SELECT * FROM foonecessidades 24! segundos.
Por que tanta diferença? Eu não sei, mas de alguma forma me parece um problema de design muito sério no MySQL, ou um bug.
MySQL 8.0.20 rodando no SLES 15.1
É um bug arquivado há 4 meses e foi corrigido no MySQL 8.0.22.
Quanto à lentidão da cópia -- Para cada linha deve-se verificar se já não existe um dup em cada
UNIQUEíndice.Duas soluções alternativas (talvez):
key_buffer_size.CREATEa tabela sem os índices, entãoADDeles.