Sintonize o desempenho e mantenha as bases de dados em Base de Dados do Azure para MySQL utilizando o sys_schema

APLICA-SE A: Base de Dados do Azure para MySQL - Base de Dados do Azure para MySQL de servidor único - Servidor Flexível

Importante

Base de Dados do Azure para MySQL - O Servidor Único está no caminho da reforma. Recomendamos vivamente que faça upgrade para Base de Dados do Azure para MySQL - Servidor Flexível. Para obter mais informações sobre migração para Base de Dados do Azure para MySQL - Servidor Flexível, veja o que está a acontecer com Base de Dados do Azure para MySQL Servidor Único?

O MySQL performance_schema, disponível pela primeira vez no MySQL 5.5, fornece instrumentação para muitos recursos vitais do servidor, tais 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 da informação necessária requer frequentemente 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 vistas fáceis de utilizar numa base de dados só de leitura e está totalmente habilitado na versão 5.7 Base de Dados do Azure para MySQL.

pontos de vista sobre sys_schema

Existem 52 pontos de vista no sys_schema, e cada vista tem um dos seguintes prefixos:

  • Host_summary ou IO: Latências relacionadas com i/O.
  • InnoDB: Estado do tampão innoDB e fechaduras.
  • Memória: Utilização da memória pelo anfitrião e pelos utilizadores.
  • Schema: Informações relacionadas com o esquema, tais como incremento automático, índices, etc.
  • Declaração: Informação sobre declarações sql; pode ser afirmação que resultou em tomografia completa da mesa, ou tempo de consulta longa.
  • Utilizador: Recursos consumidos e agrupados pelos utilizadores. Exemplos são ficheiros I/Os, ligações e memória.
  • Aguarde: Aguarde eventos agrupados por anfitrião ou utilizador.

Agora vamos olhar para alguns padrões de uso comuns da sys_schema. Para começar, vamos agrupar os padrões de utilização em duas categorias: Afinação de desempenho e manutenção de base de dados.

Otimização do desempenho

sys.user_summary_by_file_io

IO é a operação mais cara na base de dados. Podemos descobrir a latência média do IO consultando a visão sys.user_summary_by_file_io . Com o padrão de 125 GB de armazenamento fortado, a minha latência IO é de cerca de 15 segundos.

io latência: 125 GB

Como Base de Dados do Azure para MySQL escala iO no que diz respeito ao armazenamento, depois de aumentar o meu armazenamento a provisionado para 1 TB, a minha latência IO reduz para 571 ms.

io latência: 1TB

sys.schema_tables_with_full_table_scans

Apesar de um planeamento cuidadoso, muitas consultas ainda podem resultar em exames de mesa completos. Para obter informações adicionais sobre os tipos de índices e como otimizá-los, pode consultar este artigo: Como resolver problemas no desempenho da consulta. As tomografias completas são intensivas em recursos e degradam o desempenho da sua base de dados. A maneira mais rápida de encontrar mesas com a tomografia completa é consultar a vista sys.schema_tables_with_full_table_scans .

tomografias de mesa completas

sys.user_summary_by_statement_type

Para resolver problemas de desempenho na base de dados, pode ser benéfico identificar os eventos que ocorram dentro da sua base de dados, e usar a visão sys.user_summary_by_statement_type pode apenas fazer o truque.

resumo por declaração

Neste exemplo, Base de Dados do Azure para MySQL gastou 53 minutos a lavar o registo de consulta slog 44579 vezes. É muito tempo e muitos iOs. Pode reduzir esta atividade desativando o seu registo de consulta lenta ou diminuindo a frequência do login de consulta lenta para o portal do Azure.

Manutenção de bases de dados

sys.innodb_buffer_stats_by_table

[! IMPORTANTE]

Consultar esta vista pode ter impacto no desempenho. Recomenda-se a realização desta resolução de problemas durante o horário comercial fora do pico.

A piscina tampão InnoDB reside na memória e é o principal mecanismo de cache entre o DBMS e o armazenamento. O tamanho do conjunto de tampão InnoDB está ligado ao nível de desempenho e não pode ser alterado a menos que um produto diferente SKU seja escolhido. Tal como acontece com a memória no seu sistema operativo, as páginas antigas são trocadas para dar espaço a dados mais frescos. Para saber quais as tabelas que consomem a maior parte da memória da piscina tampão InnoDB, pode consultar a vista sys.innodb_buffer_stats_by_table .

Estado do tampão InnoDB

No gráfico acima, é evidente que além de tabelas e vistas do sistema, cada mesa na base de dados mysqldatabase033, que acolhe 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 da leitura, mas incorrem em custos adicionais para inserções e armazenamento. Sys.schema_unused_indexes e sys.schema_redundant_indexes fornecer informações sobre índices não reutilizados ou duplicados.

índices não reutilizados

índices redundantes

Conclusão

Em resumo, o sys_schema é uma ótima ferramenta tanto para afinação de desempenho como para manutenção de bases de dados. Certifique-se de aproveitar esta funcionalidade na sua Base de Dados do Azure para MySQL.

Passos seguintes

  • Para encontrar respostas de pares às suas perguntas mais preocupadas ou publicar uma nova pergunta/resposta, visite Stack Overflow.