Início / dba / Perguntas / 150055
Accepted
Mark Amery
Asked: 2016-09-20 06:22:56 +0800 CST

Limite a instrução DDL para evitar afetar o desempenho de outras consultas

  • 772

No MySQL, existe alguma maneira de fazer uma ALTER TABLEou outra instrução DDL ser executada mais lentamente, para mitigar seu impacto no desempenho de outras consultas no mesmo banco de dados? Descobri que uma instrução DDL de execução longa pode prejudicar o desempenho de outras consultas no banco de dados e gostaria de poder fazer ALTERtabelas enormes sem sofrer esse impacto.

Para ser claro, esta questão não é sobre bloqueios - o DDL online resolve a maioria dos nossos problemas de bloqueio e nos permite executar comandos DDL em grandes tabelas sem bloquear totalmente as gravações na tabela. Trata-se apenas de mitigar o impacto no desempenho que a carga pesada de CPU e E/S imposta pela execução de uma instrução DDL em uma tabela grande pode ter no servidor MySQL. Também não estou interessado em estratégias que envolvam configurar um escravo replicante em outro computador e executar a instrução DDL lá; Eu sei que isso é possível, mas preferiria a abordagem mais leve de apenas limitar o DDL, se possível.

O MySQL tem a palavra- LOW_PRIORITYchave para instruções DML para mitigar seu impacto no desempenho, e há alguma discussão no Stack Overflow sobre o problema de princípio semelhante de mitigar o impacto no desempenho demysqldump , mas não consigo encontrar nada semelhante para ALTER TABLEinstruções.

mysql performance

1 respostas

  1. Best Answer

    Espero que suas tabelas sejam InnoDB, não MyISAM. Alguns dos itens a seguir não funcionarão bem com o MyISAM.

    Plano A: Use o pt-online-schema-change da Percona. É autoafogável.

    Plano B: (Você não gosta disso.) Muitos ALTERspodem, especialmente em 5.6 ou 5.7, correr ALGORITHM=INPLACE, tornando-o muito menos invasivo do que o caminho ( ALGORITHM=COPY).

    Plano C: (Você não gosta disso.) Jogue jogos de replicação. Isso leva a um impacto praticamente zero em outras consultas.

    Plano D: Replicação baseada em Galera (PXC, MaraiDB+Galera, etc). Este também é um jogo de replicação, mas as ferramentas provavelmente tornam menos esforço para o DBA.

    Plano E: Se você estiver adicionando uma coluna, crie uma tabela paralela para a(s) coluna(s) extra(s). Isso tem impacto zero para configurar.

    Plano F: Tenha uma camada de código para ocultar a tabela original da tabela modificada. Escreva algum código extra para lidar com a transição, sem tempo de inatividade, independentemente de quanto tempo demore.

    Plano G: Pague pelo MEB - ele joga alguns jogos bacanas para tornar o backup mais rápido.

    • 1

relate perguntas