Ajustar o desempenho e manter 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 ÚnicoBanco de Dados do Azure para MySQL – Servidor Flexível

O performance_schema do MySQL, disponível primeiramente no MySQL 5.5, fornece instrumentação para muitos recursos de servidor essenciais, como alocação de memória, programas armazenados, bloqueio de metadados etc. No entanto, o performance_schema contém mais de 80 tabelas e, a obtenção as informações necessárias, muitas vezes, exige a junção das tabelas de performance_schema, assim como das tabelas de information_schema. Com base no performance_schema e o information_schema, o sys_schema fornece uma coleção avançada de exibições amigáveis de usuário em um banco de dados somente leitura e é totalmente habilitado no servidor flexível do Banco de Dados do Azure para MySQL versão 5.7.

Há 52 exibições no sys_schema e cada uma tem um dos prefixos a seguir:

• Host_summary ou E/S: Latências relacionadas à E/S.
• InnoDB: Bloqueios e status do buffer InnoDB.
• Memória: Uso de memória pelo host e pelos usuários.
• Esquema: Informações relacionadas ao esquema, como incremento automático, índices e etc.
• Instrução: Informações sobre instruções SQL; pode ser uma instrução que resultou em verificação de tabela completa ou tempo de consulta longa.
• Usuário: Recursos consumidos e agrupados pelos usuários. Exemplos são E/S de arquivos, conexões e memória.
• Aguarde: Aguarda eventos agrupados por host ou usuário.

Agora, vejamos alguns padrões comuns de uso 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.

Ajuste de desempenho

sys.user_summary_by_file_io

E/S é a operação mais cara no banco de dados. É possível localizar a latência média de E/S, consultando a exibição sys.user_summary_by_file_io. Com o padrão de 125 GB de armazenamento provisionado, a latência de E/S é de aproximadamente 15 segundos.

Como o servidor flexível do Banco de Dados do Azure para MySQL escala a E/S em relação ao armazenamento, após aumentar o armazenamento provisionado para 1 TB, a latência de E/S é reduzida para 571 ms.

sys.schema_tables_with_full_table_scans

Apesar do planejamento cuidadoso, muitas consultas ainda podem resultar em verificações de tabela completas. Para saber mais sobre os tipos de índices e como otimizá-los, confira este artigo: Como solucionar problemas de desempenho de consultas. As verificações de tabela completas são tarefas com uso intensivo de recursos e prejudicam o desempenho do banco de dados. A maneira mais rápida de localizar tabelas com verificação de tabela completa é consultar a exibiçã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 útil identificar os eventos que ocorrem dentro dele e usar a exibição sys.user_summary_by_statement_type pode ser o ideal.

Neste exemplo, o servidor flexível do Banco de Dados do Azure para MySQL gastou 53 minutos liberando o log de consultas lentas 44579 vezes. Isso é muito tempo e muitas E/Ss. É possível reduzir essa atividade desabilitando o log de consultas lentas ou diminuindo a frequência do logon de consultas lentas no portal do Azure.

Manutenção de banco de dados

sys.innodb_buffer_stats_by_table

[!IMPORTANT]

Consultar essa exibição pode afetar o desempenho. Recomendamos executar essa solução de problemas fora do horário comercial de pico.

O pool de buffers InnoDB reside na memória e é o mecanismo de cache principal entre o SGBD e o armazenamento. O tamanho do pool de buffers do InnoDB está vinculado ao nível de desempenho e não pode ser alterado, a menos que outro SKU de produto for escolhido. Assim como acontece com a memória no sistema operacional, as páginas antigas são trocadas para criar espaço para dados mais atuais. Para localizar quais tabelas consomem a maior parte da memória do pool de buffers InnoDB, você pode consultar a exibição sys.innodb_buffer_stats_by_table.

No gráfico acima, é evidente que, além das exibições e tabelas do sistema, cada tabela no banco de dados mysqldatabase033, que hospeda um dos sites do WordPress, ocupa 16 KB, ou uma página, de dados na memória.

Sys.schema_unused_indexes e sys.schema_redundant_indexes

Os índices são excelentes ferramentas para melhorar o desempenho de leitura, mas eles incorrem em custos adicionais para inserções e armazenamento. Sys.schema_unused_indexes e sys.schema_redundant_indexes fornecem informações sobre índices duplicados ou não utilizados.

Conclusão

Em resumo, o sys_schema é uma ótima ferramenta para ajuste de desempenho e manutenção de banco de dados. Aproveite esse recurso na instância do seu servidor flexível do Banco de Dados do Azure para MySQL.

Próximas etapas

• Para localizar respostas de pares às suas perguntas mais preocupantes ou publicar uma nova pergunta/resposta, acesse o Stack Overflow.