Princípios e notas de otimização de desempenho do MySQL:
1. O MySQL alocará uma memória (sort_buffer) para cada thread para classificação. O tamanho da memória é sort_buffer_size
1> Se a quantidade de dados classificados for menor que sort_buffer_size, a classificação será feita na memória.
2> Se a quantidade de dados classificados for muito grande para armazenar tantos dados na memória, um arquivo de disco temporário será usado para ajudar a classificação, também conhecida como classificação externa.
3> Ao usar classificação externa, o MySQL irá dividir em vários arquivos temporários separados para armazenar os dados classificados e, em seguida, mesclar esses arquivos em um arquivo grande
2. mysql irá ler os dados que atendem às condições para sort_buffer percorrendo o índice, e rapidamente classificar de acordo com o campo de classificação
1> Se o campo de consulta não estiver incluído no índice auxiliar, você precisará retornar o índice clusterizado para recuperar os campos obrigatórios de acordo com a chave primária do registro do índice auxiliar.
2> Este método causará IO aleatório. No MySQL5.6 , o mecanismo MRR é fornecido, o que mudará o índice auxiliar. A chave primária do registro correspondente é retirada e classificada na memória e, em seguida, de volta à tabela
3> Crie um índice conjunto de acordo com a situação para evitar a perda de desempenho causada por classificação. Se permitido, você também pode construir um índice de cobertura para evitar o retorno à tabela.
O princípio de duas formas de classificação:
Classificar todos os campos
1. Leia todos os campos obrigatórios em sort_buffer por meio do índice
2. Classifique de acordo com o campo de classificação
3. Retorne o conjunto de resultados para o cliente
Desvantagens:
1. Como resultado, o sort_buffer não pode armazenar muitos dados, porque além do campo de classificação, outros campos são armazenados e a eficiência de uso de sort_buffer não é alta
. 2. Quando a quantidade de dados a serem classificados é grande. , haverá muitos arquivos temporários e o desempenho de classificação será muito alto.
Prós fracos: o MySQL priorizará a classificação de campo completo quando a memória for grande o suficiente, porque este método evita uma operação de retorno de tabela em comparação com a classificação de rowid
Classificar por rowid
1. Controlando o comprimento dos dados de linha classificados para armazenar o máximo de dados possível no sort_buffer, max_length_for_sort_data
2. Apenas os campos e chaves primárias que precisam ser classificados são lidos no sort_buffer e classificados de acordo com o campo de classificação
3 .De acordo com a Ordem ordenada, pegue o id para retornar à tabela para recuperar os dados que deseja obter
4. Devolva o conjunto de resultados para o cliente
Vantagens: melhor aproveitamento da memória sort_buffer para operações de ordenação, minimiza o acesso ao disco
Desvantagens : a operação de retorno à tabela é IO aleatório, causará muitas leituras aleatórias, não necessariamente menos do que a classificação de campo completo para reduzir o acesso ao disco
3. Retorne o número de linhas tomadas pelo cliente de acordo com o resultado classificado
1. Os atrasos principais e de espera,
É a diferença entre o tempo de conclusão da execução da mesma transação no banco de dados de reserva e o tempo de conclusão da execução do banco de dados principal, incluindo o tempo de conclusão da execução da transação do banco de dados principal e o log bin enviado ao banco de dados de reserva, a diferença entre o tempo de conclusão da execução da transação do banco de dados em espera. O tempo de atraso seconds_behind_master de cada transação, há um campo de tempo no log binário de cada transação, que é usado para registrar o tempo de gravação no banco de dados principal, e o banco de dados de reserva tira o valor do campo de tempo da transação atualmente em execução e calcula isso e a diferença de tempo do sistema atual.
2. A origem do atraso entre o ativo e o modo de espera:
① Em primeiro lugar, sob algumas condições de implantação, o desempenho da máquina onde o banco de dados de reserva está localizado é pior do que o desempenho da máquina onde o banco de dados principal está localizado. O motivo é que vários bancos de dados de reserva são implantados na mesma máquina. grande número de consultas causará competição por recursos io. A solução é a configuração "Double 1", tanto o redo log quanto o binlog gravam somente o cache de página fs
②A pressão do banco de dados de reserva é alta, e o motivo é que um grande número de operações de consulta são realizadas no banco de dados de reserva, o que consome muitas CPUs, resultando em atrasos na sincronização. A solução é usar um mestre e vários escravos, e vários escravos para reduzir a pressão de consulta do backup
③ Transação grande, porque se a operação dml de uma grande transação faz com que o tempo de execução seja muito longo, o binlog da transação é enviado para o banco de dados de reserva, e o banco de dados de reserva também precisa ser executado por tanto tempo, o que causa o atraso do principal e standby.A solução é minimizar as grandes transações, como a operação de exclusão, usando o limite para excluir em lotes, pode evitar grandes transações e reduzir o escopo do bloqueio.
④ O ddl de uma grande tabela fará com que a biblioteca principal envie seu ddl binlog para o banco de dados de reserva, e o banco de dados de reserva analisa o log de transferência, sincroniza e envia o dml binlog subsequente. É necessário aguardar o bloqueio de gravação do mdl do ddl a ser liberado, o que causa os atrasos principal e de espera.
3. Estratégia de prioridade de confiabilidade,
① Determine se seconds_behind_master do banco de dados de espera B é menor que um certo valor (por exemplo, 5 segundos), continue para a próxima etapa, caso contrário, continue tentando esta etapa novamente
② Altere a biblioteca principal A para o status somente leitura, ou seja, defina somente leitura como verdadeiro,
③ Julgando o valor de seconds_behind_master do banco de dados de reserva B até que este valor se torne 0; Alterar o banco de dados de reserva B para legível e gravável significa definir somente leitura para falso; Alternar a solicitação de negócios para banco de dados de reserva, entendo se o log bin enviado há várias transações no registro de transferência e o tempo em que o negócio está indisponível é o tempo total em que várias transações são usadas. Se a biblioteca principal for desligada em condições anormais, isso causará problemas. Se o tempo de atraso entre a biblioteca em espera e a biblioteca principal for curto, o negócio pode ser usado normalmente após o registro de transferência ser usado. Se o registro de transferência não foi já foi usado, alternar para O banco de dados de backup causará a transação concluída anteriormente, "perda de dados", mas é inaceitável em alguns cenários de negócios.
4. Estratégia de usabilidade, problemas:
Em double m, e binlog_format = mixed, isso levará à inconsistência dos dados primários e secundários.Ao usar binlog de formato de linha, o problema de inconsistência de dados é mais fácil de encontrar, porque binlog row registra todos os valores do campo.
Hoje, a professora também falou sobre a necessidade de se ter cuidado primeiro, a prevenção provavelmente se dá por meio destes pontos:
1. Controle de permissão e distribuição (banco de dados e permissões de servidor)
2. Faça especificações de operação
3. Treinamento regular para desenvolvimento
4. Construa banco de dados de backup atrasado
5. Faça um bom trabalho de auditoria SQL, contanto que seja uma instrução que altere as operações em os dados online (DML e DDL) precisam ser auditados
6. Faça um backup. O backup é dividido em dois pontos.
(1) Se a quantidade de dados for relativamente grande, use o backup físico xtrabackup. Execute backups completos do banco de dados regularmente ou backups incrementais.
(2) Se a quantidade de dados for pequena, use mysqldump ou mysqldumper. Em seguida, use o binlog para restaurar ou construir uma maneira mestre-escravo de restaurar dados.
Também é necessário fazer backup do arquivo binlog regularmente.Também é
necessário verificar regularmente se o arquivo de backup está disponível.Se ocorrer uma operação incorreta e os dados precisam ser restaurados, o arquivo de backup fica indisponível, o que é ainda mais trágico.
Se ocorrer uma operação de exclusão de dados, ela pode ser recuperada a partir dos seguintes pontos:
1. As instruções de operação incorreta de DML causam incompletude ou perda de dados. Você pode usar o flashback, mas atualmente estamos usando o myflash de Meituan, que também é uma boa ferramenta, e a essência é a mesma. Ambos analisam o evento binlog primeiro e depois o revertem. Inverta excluir para inserir, inserir para excluir e reverter a imagem antes e depois da atualização. Portanto, você deve definir binlog_format = row e binlog_row_image = full.Lembre-
se de que ao restaurar dados, você deve primeiro restaurar para uma instância temporária e, em seguida, restaurar de volta para a biblioteca principal.
2. Operação incorreta da instrução DDL (truncar e descartar), porque a instrução DDL não importa se o binlog_format é linha ou instrução.No binlog, apenas a instrução é registrada, não a imagem, por isso é relativamente mais problemático restaurar. Os dados só podem ser restaurados por backup completo + log bin do aplicativo. Uma vez que a quantidade de dados é relativamente grande, o tempo de recuperação é particularmente longo.