Ajuste o desempenho e mantenha bancos de dados no Banco de Dados do Azure para MySQL - Servidor Flexível usando o sys_schema
APLICA-SE A: Banco de Dados do Azure para MySQL - Servidor
Único Banco de Dados do Azure para MySQL - Servidor Flexível
Importante
O servidor único do Banco de Dados do Azure para MySQL está no caminho de desativação. É altamente recomendável que você atualize para o Banco de Dados do Azure para o servidor flexível MySQL. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para servidor flexível MySQL, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único MySQL?
O performance_schema MySQL, disponível pela primeira vez no MySQL 5.5, fornece instrumentação para muitos recursos vitais do servidor, como alocação de memória, programas armazenados, bloqueio de metadados, etc. No entanto, o performance_schema contém mais de 80 tabelas, e obter as informações necessárias muitas vezes requer a junção de tabelas dentro do performance_schema e tabelas do information_schema. Com base em performance_schema e information_schema, o sys_schema fornece uma poderosa coleção de exibições amigáveis em um banco de dados somente leitura e está totalmente habilitado no Banco de Dados do Azure para servidor flexível MySQL versão 5.7.
Há 52 modos de exibição no sys_schema e cada modo de exibição tem um dos seguintes prefixos:
- Host_summary ou E/S: latências relacionadas a E/S.
- InnoDB: Status e bloqueios do buffer InnoDB.
- Memória: Uso de memória pelo host e usuários.
- Esquema: Informações relacionadas ao esquema, como incremento automático, índices, etc.
- Instrução: Informações sobre instruções SQL; Pode ser uma instrução que resultou em uma verificação completa da tabela ou um longo tempo de consulta.
- Usuário: Recursos consumidos e agrupados pelos usuários. Exemplos são E/S de arquivos, conexões e memória.
- Esperar: Aguarde eventos agrupados por host ou usuário.
Agora vamos ver alguns padrões de uso comuns do sys_schema. Para começar, agruparemos os padrões de uso em duas categorias: Ajuste de desempenho e Manutenção de banco de dados.
Afinação de Desempenho
sys.user_summary_by_file_io
IO é a operação mais cara no banco de dados. Podemos descobrir a latência média de E/S consultando a visualização sys.user_summary_by_file_io . Com os 125 GB de armazenamento provisionado padrão, minha latência de E/S é de cerca de 15 segundos.
Como o servidor flexível do Banco de Dados do Azure para MySQL dimensiona a E/S em relação ao armazenamento, depois de aumentar meu armazenamento provisionado para 1 TB, minha latência de E/S reduz para 571 ms.
sys.schema_tables_with_full_table_scans
Apesar do planejamento cuidadoso, muitas consultas ainda podem resultar em verificações completas da tabela. Para obter mais informações sobre os tipos de índices e como otimizá-los, consulte este artigo: Como solucionar problemas de desempenho de consulta. As verificações completas de tabelas consomem muitos recursos e degradam o desempenho do banco de dados. A maneira mais rápida de encontrar tabelas com verificação de tabela completa é consultar a visualização sys.schema_tables_with_full_table_scans .
sys.user_summary_by_statement_type
Para solucionar problemas de desempenho do banco de dados, pode ser benéfico identificar os eventos que acontecem dentro do seu banco de dados, e usar a visualização sys.user_summary_by_statement_type pode fazer o truque.
Neste exemplo, o Banco de Dados do Azure para servidor flexível MySQL gastou 53 minutos liberando o log de consulta lenta 44579 vezes. Isso é muito tempo e muitos IOs. Você pode reduzir essa atividade desativando seu log de consulta lenta ou diminuindo a frequência de logon de consulta lenta no portal do Azure.
Manutenção da base de dados
sys.innodb_buffer_stats_by_table
[! IMPORTANTE]
Consultar essa exibição pode afetar o desempenho. Recomenda-se executar essa solução de problemas fora do horário comercial de pico.
O pool de buffers InnoDB reside na memória e é o principal mecanismo de cache entre o DBMS e o armazenamento. O tamanho do buffer pool InnoDB está vinculado à camada de desempenho e não pode ser alterado, a menos que uma SKU de produto diferente seja escolhida. Tal como acontece com a memória no seu sistema operativo, as páginas antigas são trocadas para criar espaço para dados mais recentes. Para descobrir quais tabelas consomem a maior parte da memória do pool de buffers InnoDB, você pode consultar a visualização sys.innodb_buffer_stats_by_table .
No gráfico acima, é evidente que, além das tabelas e visualizações do sistema, cada tabela no banco de dados mysqldatabase033, que hospeda um dos meus sites WordPress, ocupa 16 KB, ou 1 página, de dados na memória.
Sys.schema_unused_indexes & sys.schema_redundant_indexes
Os índices são ótimas ferramentas para melhorar o desempenho de leitura, mas incorrem em custos adicionais para inserções e armazenamento. Sys.schema_unused_indexes e sys.schema_redundant_indexes fornecem informações sobre índices não utilizados ou duplicados.
Conclusão
Em resumo, o sys_schema é uma ótima ferramenta para ajuste de desempenho e manutenção do banco de dados. Certifique-se de aproveitar esse recurso em sua instância de servidor flexível do Banco de Dados do Azure para MySQL.
Próximos passos
- Para encontrar respostas de colegas para suas perguntas mais preocupadas ou postar uma nova pergunta/resposta, visite Stack Overflow.