Início / dba / Perguntas / 87459
Accepted
Mannoj
Asked: 2015-01-03 08:54:17 +0800 CST

Soltando várias CHAVES de uma tabela

  • 772

Soltar várias CHAVES em uma tabela é uma opção preferida ou uma por uma é a preferida?

“SOLTE A CHAVE A, SOLTE A CHAVE B, SOLTE A CHAVE C"

Por mais 900 milhões de registros na tabela.

Como funciona internamente?

mysql innodb

1 respostas

  1. Best Answer

    A eliminação de vários índices em um único comando SQL é muito melhor. Por quê ?

    CENÁRIO 1

    ALTER TABLE mytable DROP INDEX ndx1;
ALTER TABLE mytable DROP INDEX ndx2;
ALTER TABLE mytable DROP INDEX ndx3;

    Isso é o que aconteceria

    • Cria uma tabela temporária vazia
    • Remove o índice da tabela temporária vazia
    • Copia os dados para a tabela temporária
    • Troca a tabela temporária pela tabela original
    • Elimina a tabela original

    Dentro #SCENARIO #1, isso aconteceria três vezes.

    CENÁRIO #2

    ALTER TABLE mytable
    DROP INDEX ndx1,
    DROP INDEX ndx2,
    DROP INDEX ndx3
;

    Você acreditaria que o MySQL costumava fazer essa transformação 3 vezes em 2006 no MySQL 4.1? Em outras palavras, SCENARIO #2seria tratado como SCENARIO #1. Na verdade, escrevi uma postagem no Fórum de discussão geral MySQL AB solicitando que isso fosse alterado ( Por que o índice de queda do mysql é muito lento em uma tabela grande? ).

    Alguém perguntou no DBA StackExchange se o MySQL ainda fazia isso. Eu escrevi uma postagem aqui dizendo que esse não é mais o caso ( o MySQL ainda lida com índices dessa maneira? ) e essa pergunta faz referência à minha postagem original do MySQL AB .

    O que o MySQL faz hoje é o seguinte:

    • Cria uma tabela temporária
    • Executa os 3 comandos ALTER TABLE na tabela temporária vazia
    • Copia os dados para a tabela temporária UMA VEZ
    • Troca a tabela temporária pela tabela original
    • Elimina a tabela original

    Portanto, você pode confiar que o MySQL fará a coisa certa hoje.

    Você deve ir com SCENARIO #2.

    DE UMA CHANCE !!!

    ATUALIZAÇÃO 2015-01-02 13:06 EST

    você acabou de perguntar

    O que acontecerá com as novas operações na tabela? Onde os novos registros serão armazenados no momento da cópia? Seria necessário bloqueio de tabela ou bloqueio de metadados?

    A mesa ficará bloqueada o tempo todo. Claro, SCENARIO #1será bloqueado três vezes mais do que SCENARIO #2. Se você não pode perder tempo para isso, só tem uma opção: pt-online-schema-change . Todos os seus INSERTs, UPDATEs e DELETEs serão tratados adequadamente durante a alteração.

    ATUALIZAÇÃO 2015-01-03 08:33 EST

    @eroomydna acabou de postar um comentário .

    @rolando, você considerou o efeito de dev.mysql.com/doc/refman/5.5/en/innodb-create-index.html e é padrão em 5.6. A tabela não deve ser reconstruída com o ddl agrupado acima. Não há necessidade de usar pt-osc para esta operação.

    @eroomydna está certo em apontar isso. A URL que ele forneceu fornece informações sobre isso.

    Para sua pergunta específica, @eroomydna diz que não precisa de pt-online-schema-change , e ele está certo neste caso porque você está descartando três índices. Observe os detalhes de implementação da criação rápida de índice, parágrafo 2 :

    A eliminação de um índice secundário é simples. Somente as tabelas internas do sistema InnoDB e as tabelas do dicionário de dados MySQL são atualizadas para refletir o fato de que o índice não existe mais. O InnoDB retorna o armazenamento usado para o índice para o espaço de tabela que o continha, para que novos índices ou linhas de tabela adicionais possam usar o espaço.

    Você tem uma tabela de 900 milhões e provavelmente muitas páginas de índice para os três índices. A eliminação do índice está sendo feita de maneira lógica e deve invalidar todas essas páginas para tornar o espaço reutilizável. Isso também criará muitos bloqueios compartilhados, permitindo leituras e bloqueando gravações. Portanto, esta operação deve ser relativamente rápida. Quanto tempo leva, eu não posso te dizer. Como você disse que não pode perder o tempo de inatividade, pode levar segundos, minutos, talvez até horas para uma mesa ao vivo com muitos bloqueios compartilhados e gravações bloqueadas.

    Se você tiver uma cópia da tabela em um DEV ou servidor de teste, execute-o DROP KEY A,DROP KEY B,DROP KEY Capenas para ver a velocidade de execução. Então, você pode considerar se o tempo de inatividade valeria a pena. No entanto, se você deseja que a tabela esteja ativa e realmente não possa fazer o tempo de inatividade, ainda assim deve usar pt-online-schema-change .

    Quanto à minha resposta, ela se aplicaria apenas se

    • você solta um índice e cria um índice com o mesmo nome
    • solte/adicione a CHAVE PRIMÁRIA
    • 10

relate perguntas