Temos uma aplicação combinada / servidor MySQL que começou a desmoronar. No momento, ele fica preso ao copiar uma tabela MySQL MyISAM de 125 milhões de linhas ( INSERT INTO a_copy SELECT * FROM a com KEYS DISABLED on a_copy ). Nós comparamos o trabalho do qual esta consulta faz parte com menos de uma hora de dados de produção em uma VM de produção clonada. No entanto, ao executar este trabalho em produção, a consulta de cópia está em execução por mais de 12 horas sem concluir, tornando aleatoriamente cada consulta do MySQL mais lenta que o melaço (60 segundos, sem travas).
Saída do iostat
yyyy@xxxx:~$ iostat -mxdc 10
Linux 2.6.32-5-686 (xxxx) 12/24/14 _i686_ (4 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
5.24 0.00 1.34 13.43 0.00 80.00
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sda 1.84 232.18 68.24 468.50 1.88 2.74 17.62 47.19 87.87 0.69 36.79
avg-cpu: %user %nice %system %iowait %steal %idle
0.77 0.00 2.26 27.92 0.00 69.05
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sda 6.70 6.10 317.30 208.20 1.37 0.83 8.56 140.26 173.99 1.90 100.00
avg-cpu: %user %nice %system %iowait %steal %idle
0.81 0.00 2.58 31.64 0.00 64.97
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sda 5.00 11.50 372.80 242.80 1.56 1.00 8.54 146.50 321.34 1.62 100.00
avg-cpu: %user %nice %system %iowait %steal %idle
0.17 0.00 1.65 39.42 0.00 58.76
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sda 3.00 23.40 226.80 618.00 0.94 2.50 8.34 145.54 171.94 1.18 100.00
avg-cpu: %user %nice %system %iowait %steal %idle
0.22 0.00 1.77 32.23 0.00 65.78
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sda 5.70 22.50 282.10 491.80 1.18 2.02 8.45 145.72 182.10 1.29 100.00
Como devo interpretar isso?
A melhor solução que encontrei e estabeleci na produção foi encontrada em link .
Usando SHOW INDEX IN a WHERE Key_name='PRIMARY' , identifico a chave primária da (s) tabela (s) e anexe um ORDER BY à consulta. A solução final se parece com INSERT INTO a_copy SELECT * FROM a ORDER BY aID, aOtherColumn , onde a chave primária de a é ( aID, aOtherColumn ).
Embora eu não esteja muito feliz com isso, funciona razoavelmente bem e, acima de tudo, muito melhor que a versão original.
EDIT: Embora o erro seja identificado corretamente, esta solução não ajuda . Quando o MySQL ADD PRIMARY KEY s, ele copia novamente a tabela semelhante a INSERT INTO a_copy SELECT * FROM a , o que deixa o mesmo problema novamente. Verifique minha outra resposta neste tópico.
Então, descobri por meio dos tamanhos dos arquivos em /var/lib/mysql/<mydb>/a* , onde o arquivo de índice ( .MYI ) tinha um tamanho de arquivo significativo e crescente.
DISABLE KEYS apenas desativa chaves não exclusivas em geral e deixa as chaves primárias ativas em particular. Basicamente, a linha de 125M INSERT INTO inseriu inserções de índice de 125M em uma junção PRIMARY KEY que se manifesta como gravações aleatórias em disco, que, por sua vez, é a coisa mais cara que você pode fazer com um disco.
Portanto, minha solução é DROP PRIMARY KEY na tabela a_copy durante a cópia e, em seguida, ADD PRIMARY KEY quando a tarefa é feita.