Ajustar o desempenho e manter bancos de dados no Banco de Dados do Azure para MySQL – Servidor Flexível usando o sys_schema
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 no information_schema, o sys_schema fornece uma coleção avançada de exibições amigáveis ao 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 obter mais informações sobre os tipos de índices e como otimizá-los, você pode consultar este artigo: Desempenho da consulta de perfil no Banco de Dados do Azure para MySQL – Servidor Flexível usando EXPLAIN. 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 benéfico identificar os eventos que ocorrem dentro do banco de dados e usar o modo de exibição sys.user_summary_by_statement_type pode apenas fazer o truque.
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 à camada de desempenho e não pode ser alterado, a menos que uma SKU de produto diferente seja escolhida. 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. Certifique-se de aproveitar esse recurso na sua instância do Servidor Flexível do Banco de Dados do Azure para MySQL.