Explorando a arquitetura subjacente do MySQL: uma visão geral do processo de design e implementação

Curtidas ainda são obrigatórias, caso apareça um bonitão na frente da tela, só curtir! ! ! !

Autor: Mr. Raymon em Source Code Times

diga na frente

Mysql, como um sistema de gerenciamento de banco de dados excelente e amplamente utilizado, é quase uma parte indispensável do desenvolvimento diário para muitos engenheiros Java. Seja armazenando dados massivos ou recuperando e gerenciando dados com eficiência, o Mysql desempenha um papel importante. No entanto, além de usar o Mysql para desenvolvimento diário, realmente entendemos sua arquitetura subjacente e o processo de design e implementação? Este blog levará você a uma exploração aprofundada do processo de design e implementação da arquitetura subjacente do Mysql, ajudando você a entender e aplicar melhor esse poderoso sistema de banco de dados. Vamos descobrir o mistério da camada inferior do Mysql juntos e explorar seus mistérios.

1. Como é o Mysql aos seus olhos?

O MySQL, aos olhos da maioria dos engenheiros Java comuns, é frequentemente visto como uma ferramenta para armazenar e manipular dados. Costumamos usá-lo para criar bancos de dados, criar tabelas e índices, para adicionar, excluir, modificar e consultar dados. Esses métodos básicos de uso tornaram-se operações de rotina ao lidar com o MySQL em nosso trabalho diário. (Como a foto abaixo)

No entanto, no desenvolvimento diário, geralmente nos concentramos apenas em como usar corretamente o MySQL para operações de dados e raramente temos uma compreensão profunda da arquitetura subjacente e dos princípios de implementação do MySQL. Podemos saber pouco sobre os mecanismos subjacentes, como mecanismos de armazenamento, otimizadores de consulta e gerenciamento de transações, e temos conhecimento limitado sobre como otimizar o desempenho, garantir a consistência dos dados e fazer backup e recuperação.
Por causa disso, é muito importante para nós entendermos o processo de design e implementação da arquitetura subjacente do MySQL. Ele pode não apenas nos ajudar a entender melhor o mecanismo interno do MySQL, mas também melhorar nossa eficiência e qualidade de trabalho. No conteúdo a seguir, discutiremos em profundidade os vários componentes e tecnologias da arquitetura subjacente do MySQL, esperando trazer a você um conhecimento mais profundo e abrangente do MySQL. Vamos desvendar o véu subjacente do MySQL e explorar seus mistérios

2. Como o sistema Java se conecta ao Mysql?

Em Java, conectar-se a um banco de dados MySQL geralmente requer JDBC (Java Database Connectivity). JDBC é um conjunto de APIs fornecidas pelo Java para acessar bancos de dados.Ele fornece uma interface padrão que permite interagir com vários bancos de dados por meio de código Java.

Para se conectar ao banco de dados MySQL, primeiro você precisa garantir que o banco de dados MySQL tenha sido instalado no sistema e que o driver MySQL JDBC apropriado tenha sido importado para o projeto Java. O driver Mysql constrói uma ponte entre o sistema Java e o banco de dados Msyql para nós:

Portanto, quando estamos implementando código de negócios, se precisarmos executar instruções SQL relacionadas, o driver Mysql pode nos ajudar a passar as instruções SQL para o banco de dados Mysql para execução: Então, vamos pensar em uma pergunta: um sistema Java pode seguir apenas o

Does o banco de dados estabelece uma conexão? Isso definitivamente não é possível, pois precisamos entender uma verdade. Suponha que desenvolvemos um sistema web em Java e o implantamos no Tomcat, então o próprio Tomcat deve ter várias threads para processar várias solicitações simultaneamente. Vejamos a figura abaixo: Portanto

, quando houver várias solicitações de negócios, podemos estabelecer uma conexão de banco de dados para cada solicitação para uso separado, conforme a seguir: Mas
em um cenário de alta simultaneidade, se cada thread do Tomcat acessar o banco de dados. É possível conectar a um banco de dados, execute um instrução SQL e, em seguida, destruir a conexão? Pode haver centenas de threads realizando esse processo com frequência. Esta abordagem não é aconselhável. Leva tempo para estabelecer uma conexão com o banco de dados todas as vezes. Quando a conexão é estabelecida e a instrução SQL é executada, a conexão é destruída e a conexão é restabelecida. Isso é muito ineficiente.

Portanto, precisamos introduzir o conceito de pool de conexão para resolver esse problema. O pool de conexões mantém um conjunto de conexões de banco de dados reutilizáveis ​​e gerencia as conexões com eficiência. Quando o encadeamento do Tomcat precisa acessar o banco de dados, ele pode obter uma conexão disponível no pool de conexões e retornar a conexão ao pool de conexões após a execução. Isso pode reduzir a criação e destruição frequentes de conexões e melhorar o desempenho. Do seguinte modo:

3. Por que o Mysql também precisa de um pool de conexão?

Sabe quando você vai ao banco para fazer negócios, às vezes você tem que esperar na fila? Seria uma perda de tempo e recursos supor que todos precisam esperar que o pessoal do banco faça o negócio por eles, certo? O pool de conexões do MySQL é como um sistema de filas para transações bancárias, o que nos ajuda a gerenciar e utilizar as conexões de banco de dados com mais eficiência.

1. Melhore a eficiência da conexão: No MySQL, é necessário algum trabalho preparatório para estabelecer uma conexão com o banco de dados, assim como os funcionários do banco precisam fazer alguns preparativos antes de lidar com os negócios. Se a conexão for recriada todas as vezes, será muito ineficiente, assim como todo mundo tem que ir ao banco para fazer fila para obter um número e tratar de negócios. O pool de conexão criará algumas conexões com antecedência, assim como o banco prepara várias janelas com antecedência para o processamento do negócio, de forma que apenas uma conexão disponível possa ser obtida do pool de conexão, o que reduz o tempo de espera e melhora a eficiência da conexão.

2. Economize recursos do sistema: a conexão com o banco de dados é um recurso limitado, assim como o pessoal de um banco é limitado. Se todos usarem um membro da equipe para cuidar dos negócios, o banco ficará paralisado rapidamente. O pool de conexões pode gerenciar e controlar o número de conexões, semelhante ao número de janelas de controle do banco, para garantir que não sejam criadas muitas conexões, evitando desperdício de recursos do banco de dados e do servidor.

3. Simplifique o gerenciamento de conexões: o pool de conexões nos permite gerenciar as conexões com mais facilidade, assim como o sistema de filas de um banco permite que a equipe do banco se concentre nos negócios do cliente. Por meio do pool de conexão, não precisamos criar e liberar manualmente a conexão, basta obter a conexão do pool de conexão e usá-la e retorná-la ao pool de conexão após a conclusão. Isso simplifica o trabalho de gerenciamento de conexão e melhora a eficiência do desenvolvimento. Resumindo, o pool de conexão do MySQL é como um sistema de filas de banco, que pode melhorar a eficiência da conexão, economizar recursos do sistema, gerenciar a confiabilidade da conexão e simplificar o gerenciamento da conexão. O pool de conexão desempenha um papel importante nas operações de banco de dados de alta simultaneidade, ajudando-nos a conectar e interagir com o banco de dados MySQL de forma mais eficiente e conveniente.

4. Como o Mysql lida com solicitações de conexão?

Quando o Mysql recebe uma solicitação de conexão de rede, como ele processa a solicitação e, finalmente, como executar o SQL, vamos dar uma olhada nas etapas em todo o link do processo.
primeiro:

1. A conexão de rede deve ser atribuída a um encadeamento para processamento e um encadeamento monitora a solicitação e lê os dados da solicitação, como ler e analisar uma instrução SQL enviada pelo sistema Java a partir da conexão de rede
   .
2. Um componente é fornecido dentro do Mysql: SQL Interface (Interface SQL), que é usado para executar instruções SQL especificamente
3. Em seguida, use o otimizador de consulta: selecione o caminho de consulta ideal para executar, função: gere uma árvore de caminho de consulta para instruções SQL complexas escritas por você com dezenas de linhas, centenas de linhas ou até milhares de linhas e, em seguida, selecione uma consulta ideal a partir dela caminho para fora.
4. Chame o executor: chame a interface do mecanismo de armazenamento de acordo com o plano de execução
5. Chame a interface do mecanismo de armazenamento para realmente executar a instrução SQL. Função: O executor chamará a interface do mecanismo de armazenamento de acordo com uma determinada ordem e etapas de acordo com o plano de execução selecionado pelo otimizador e executará a lógica da instrução SQL
6. Mecanismo de armazenamento: gerencie e armazene dados, suporte uma variedade de mecanismos de armazenamento, como: InnoDB, MyISAM, Memória, podemos escolher qual mecanismo de armazenamento usar para ser responsável pela execução de instruções SQL específicas Agora, o MySQL geralmente usa o mecanismo de armazenamento InnoDB por padrão

Se você estiver interessado em todo o processo de execução acima, poderá estudá-lo em profundidade, e este artigo não apresentará os detalhes. Vamos analisar como o mecanismo de armazenamento InnoDB gerencia e armazena nossos dados.

5. Estrutura de memória importante do InnoDB: buffer pool

No mecanismo de armazenamento InnoDB, existe um componente muito importante na memória, que é o pool de buffer (BufferPool), que armazenará muitos dados em cache, para que, quando você consultar posteriormente, se tiver dados no pool de buffer de memória, apenas Você não precisa verificar o disco, vamos ver a imagem abaixo.

Por exemplo, a instrução SQL: update users set name='xxx' where id=1, por exemplo, para a linha de dados "id=1", ele primeiro verificará se a linha de dados "id=1" está em o pool de buffers, se não estiver lá, ele será carregado diretamente do disco para o pool de buffers e, em seguida, um bloqueio exclusivo será adicionado a esta linha de registros.

O buffer pool usa o algoritmo LRU (Least Recent Used) para gerenciar as páginas de dados na memória. Quando uma consulta precisa acessar dados, o InnoDB primeiro verifica se a página de dados correspondente existe no buffer pool. Se presente, ele busca os dados diretamente da memória em vez de ler do disco, o que melhora muito o desempenho da consulta. Se a página de dados não estiver no buffer pool, o InnoDB irá lê-la no buffer pool e mantê-la na memória para consultas subsequentes.

Ao configurar corretamente o tamanho do buffer pool, as páginas de dados usadas com frequência podem sempre ser mantidas na memória, melhorando a eficiência da consulta. Conjuntos de buffer maiores geralmente são adequados para servidores com grandes quantidades de memória

6. Desfazer arquivo de log: para que os dados atualizados possam ser revertidos

Arquivos de log de desfazer são usados ​​para registrar as operações de transações em andamento no banco de dados para fornecer dados de reversão quando uma transação precisa ser revertida. Quando ocorre uma operação de atualização, exclusão ou inserção, o mecanismo InnoDB registra as informações relevantes no arquivo de log Undo.

Quando uma transação precisa ser desfeita, o mecanismo InnoDB usa o log Undo para restaurar os dados ao estado anterior ao início da transação. Ele desfaz modificações nos dados revertendo a operação e restaura os dados ao seu estado anterior.

Quando carregamos o registro a ser atualizado do arquivo de disco para o buffer pool, bloqueando-o ao mesmo tempo e gravando o valor antigo antes da atualização no arquivo de log de desfazer, podemos iniciar oficialmente a atualização do registro. os registros no pool de buffers serão atualizados primeiro e os dados neste momento são dados sujos.

A chamada atualização dos dados no pool de buffer de memória aqui significa alterar o campo de nome da linha de dados "id=1" na memória
para "xxx":

7. Refazer arquivos de log: garanta a consistência e persistência dos dados

Agora vamos imaginar que se a operação de modificação na figura acima foi gravada no cache, mas não foi sincronizada com o disco para persistência no futuro; neste momento, a máquina msyql está inoperante e desliga, então os dados no cache inevitavelmente Se for perdido, os dados atualizados também serão perdidos. Portanto, para garantir a consistência e durabilidade dos dados Mysql, o mecanismo innodb introduz arquivos de redo log.

O Redo Log é um log físico usado principalmente para registrar as operações de modificação realizadas no banco de dados antes que a transação seja confirmada. Quando o banco de dados trava ou falha, o Redo Log pode ser usado para restaurar o último estado enviado para garantir a persistência dos dados.

O papel do Redo Log se reflete principalmente nos dois aspectos a seguir:

1. Recuperação de dados: quando o banco de dados falha, as operações de modificação não confirmadas podem ser reaplicadas ao banco de dados por meio do Redo Log, restaurando assim o último estado enviado.
2. Melhorar o desempenho: Ao registrar as operações de modificação no Redo Log, as operações de E/S do disco podem ser convertidas em operações de gravação sequencial, melhorando consideravelmente o desempenho de gravação do banco de dados.

Portanto, quando a operação de atualização for executada, o Mysql gravará a modificação na memória em um Redo Log Buffer, que também é um buffer na memória e é usado para armazenar o redo log. O chamado redo log serve para registrar quais modificações você fez nos dados, como alterar o valor do campo name para xxx para o registro "id=10", isso é um log. Conforme a figura abaixo:

Observações: innodb_log_buffer_size: Especifica o tamanho do buffer do Redo Log, o padrão é 8MB. Um valor maior
pode reduzir as operações de atualização frequentes e melhorar o desempenho, mas também ocupará mais memória.

8. Envie a transação: redo log flushing

Quando a transação for confirmada, os dados na área de cache no redolog serão liberados para o disco. Então, a perda de dados é importante neste momento?

Na verdade, não importa, porque se você não enviou uma transação para uma declaração de atualização, isso significa que ela falhou ao executar com sucesso. Neste momento, embora o tempo de inatividade do MySQL tenha causado a perda de todos os dados na memória, você descobrirá que os dados no disco ainda estão no estado original.

Três estratégias para gravar redo logs em disco

A estratégia de flushing é configurada através do innodb_flush_log_at_trx_commit, que possui diversas opções:

1. Se o valor do parâmetro for 0, o redo log não entra no disco, o que significa que o redo log não é liberado para o disco, ou seja, a estratégia de gravação assíncrona. Quando uma transação é confirmada, a operação de modificação do Redo Log será gravada apenas no cache de página do sistema operacional e não será descarregada no disco imediatamente. Isso fornece o melhor desempenho de gravação, mas pode resultar em algum grau de perda de dados em caso de travamento ou falha do banco de dados.
2. O valor do parâmetro é 1 e o redo log é enviado para o disco [valor padrão] significa que o Redo Log é liberado para o disco de forma síncrona. Quando a transação for confirmada, a operação de modificação do Redo Log será gravada no disco imediatamente e aguardará a conclusão da operação de IO. Ao garantir a persistência dos dados, também terá um certo impacto no desempenho. Esta é a configuração mais comumente usada e é adequada para a maioria dos cenários de aplicativos.

3. O valor do parâmetro é 2 e o redo log é inserido no cache do sistema operacional.

Indica que a operação de modificação do Redo Log é gravada no disco toda vez que uma transação é confirmada, mas não aguarda a conclusão da operação de IO. Quando uma transação é confirmada, o Redo Log é primeiro gravado no cache de página do sistema operacional e, em seguida, o thread em segundo plano libera os dados de forma assíncrona no disco. Essa configuração pode fornecer melhor desempenho e algum grau de proteção de dados, mas ainda há alguns riscos.

Seleção da estratégia de liberação
A seleção do valor innodb_flush_log_at_trx_commit apropriado depende dos requisitos para persistência e desempenho de dados. Ele pode ser definido como 1 se os requisitos de persistência de dados forem muito altos. Se o requisito de desempenho for alto e um certo grau de perda de dados for aceitável, ele pode ser definido como 0. Se você busca um melhor desempenho enquanto garante um certo grau de proteção de dados, pode optar por defini-lo como 2.

Você pode ajustar o valor innodb_flush_log_at_trx_commit modificando as configurações de parâmetro no arquivo de configuração do MySQL e reinicie o serviço MySQL para que ele entre em vigor.

Normalmente, recomendamos configurá-lo para 1. Ou seja, ao confirmar uma transação, o redo log deve ser descarregado no arquivo de disco. Isso pode garantir estritamente que, após a confirmação da transação, os dados nunca serão perdidos, porque há redo logs no arquivo de disco para restaurar todas as modificações feitas.

9. O que exatamente é binlog

Na verdade, o redo log que mencionamos antes é um tipo de redo log com tendência para a natureza física, porque registra algo assim, "qual modificação foi feita em qual registro em qual página de dados".

E o redo log em si é algo exclusivo do mecanismo de armazenamento InnoDB. O binlog é chamado de log de arquivo, que registra um log que é tendencioso para a lógica, semelhante a "atualizar uma linha de dados com id=1 na tabela de usuários, qual é o valor após a atualização", binlog não é um armazenamento InnoDB mecanismo O arquivo de log exclusivo é um arquivo de log pertencente ao próprio servidor mysql. Portanto, quando uma transação é enviada, o binlog será gravado ao mesmo tempo:
Análise da estratégia de liberação do log binlog
Para logs binlog, existem diferentes estratégias de liberação. value é 0 , quando você grava o binlog no disco, ele não entra diretamente no arquivo do disco, mas entra no cache de memória do cache do sistema operacional. Assim como na análise anterior, se a máquina estiver inoperante neste momento, seu log bin no cache do sistema operacional será perdido:

se você definir o parâmetro sync_binlog como 1, neste momento será forçado a enviar a transação O binlog é gravado diretamente no arquivo do disco, portanto, após a transação ser confirmada dessa maneira, mesmo se a máquina cair, o binlog no disco não será perdido.

Conclua o envio da transação com base no log binário e redo log

Quando gravarmos o binlog no arquivo de disco, o envio final da transação será concluído. Neste momento, o nome do arquivo binlog correspondente a esta atualização e a localização do log binlog atualizado no arquivo serão gravados no redo log Vá para o arquivo de log e escreva uma marca de confirmação no arquivo de log refazer ao mesmo tempo. Depois de concluir este assunto, o envio da transação é finalmente concluído. Vejamos o diagrama abaixo:

Qual é o significado de escrever a marca de confirmação no redo log na última etapa?

Para manter o redo log consistente com o log bin, a marca de confirmação final da transação deve ser gravada no redo log e, em seguida, a transação é confirmada com sucesso neste momento, e há um log correspondente a esta atualização no redo log, e há também é um log no log binário O log correspondente à segunda atualização, redo log e binlog são completamente consistentes

O thread de E/S em segundo plano libera aleatoriamente os dados sujos após a atualização da memória para o disco

O MySQL tem uma thread IO em segundo plano, que irá liberar aleatoriamente os dados sujos modificados no buffer pool de memória de volta para o arquivo de dados no disco em um determinado momento no futuro. Vejamos a seguinte figura: em sua thread IO Antes de liberar a thread

suja dados de volta para o disco, não importa mesmo se o mysql travar, porque após reiniciar, ele restaurará a modificação feita pela transação enviada antes de acordo com o redo log para a memória e aguardará o momento certo, o IO thread fará naturalmente esta modificação. Os dados finais são liberados para o arquivo de dados no disco.

10. Resumo

O mecanismo de armazenamento InnoDB contém principalmente alguns dados em cache na memória, como buffer pool e redo log buffer, e também contém alguns arquivos de log de desfazer, arquivos de log de redo, etc., e o próprio servidor mysql também possui arquivos de log de binlog.

Quando você executa uma atualização, cada instrução SQL corresponderá à modificação dos dados armazenados em cache no buffer pool, gravando o log de desfazer e gravando o buffer de log de redo; mas quando você envia a transação, o log de redo definitivamente será liberado no disco , o binlog é liberado para o disco e a marca de confirmação da transação no redo log é concluída; finalmente, o encadeamento de E/S em segundo plano liberará aleatoriamente os dados sujos no buffer pool para o disco.

No final da matéria ainda é obrigatório curtir, caso apareça um bonitão na frente da tela, igualzinho! ! ! !