princípio subjacente índice mysql

Passo a passo, a estrutura de dados subjacente é derivada índice mysql.

Mysql como a Internet é banco de dados muito popular, projetar o mecanismo de armazenamento e dados do motor de recuperação subjacente é muito importante, formato de armazenamento de dados, especialmente Mysql e design de índice, determinar os dados Mysql desempenho de recuperação global.

Sabemos que o papel do índice é fazer a recuperação de dados rápido, e perceber a natureza da recuperação rápida da estrutura de dados. Ao seleccionar diferentes estruturas de dados, uma variedade de dados para conseguir a recuperação rápida. No banco de dados, o algoritmo de busca eficiente é muito importante porque uma grande quantidade de dados armazenados no banco de dados, um índice eficiente pode economizar tempo tremendo. Por exemplo, a seguinte folha de dados, se não for alcançado algoritmo de indexação Mysql, em seguida, procurar id = 7 esses dados, ele só pode tomar busca travessia fim violento, encontrar id = 7 necessidade de comparar os dados sete vezes, se a tabela é armazenada em um 1000W dados encontrar id = 1000W esses dados seria comparado 1000W vezes, essa taxa é inaceitável.

Uma, a selecção de estrutura de dados de índice MySQL subjacente

1. tabela de Hash (Hash)

tabela hash é fazer uma ferramenta eficaz para a recuperação de dados rápida.

algoritmo de Hash: Também chamado algoritmo hash é valor arbitrário (chave) é convertida em chave endereço de comprimento fixo por meio de uma função hash, uma estrutura de dados de dados específicos por esse endereço.

Considere este usuário do banco de mesa, um total de sete tabelas de dados, precisamos recuperar id data = 7, sintaxe SQL é:

select \* from user where id=7;

Hashing primeiro algoritmo calcula o endereço da memória física addr = 7 ID de dados = Hash (7) = 4231, e 4231 é mapeamento endereço físico id = 0x77,0x77. 7 é um endereço físico de dados armazenados no montante, pelo que o endereço independente encontrar o correspondente nome_usuario = 'g' de dados. Este é o algoritmo de hash para recuperar dados rapidamente no processo de cálculo.

Mas há problemas de dados de colisão algoritmo de hash, que é calculada com uma função hash pode ser o resultado de contabilização de chave diferente, como de hash (7) pode ser calculado em hash (199) resultado, que é um diferentes mapas de teclado ao mesmo resultado, esta é a colisão. Uma abordagem comum é resolver o problema do método de endereço colisões Chain, que usa uma colisão lista de dados ligada após o outro para cima. Depois de calcular o valor de hash, você também precisa verificar se há uma colisão do valor hash da lista de dados, foram atravessados ​​para o final da lista, encontrar acesso directo à verdadeira chave até que os dados correspondentes.

A partir do tempo de complexidade da análise, a complexidade de tempo algoritmo hash é O (1), muito rápida recuperação. ID = 7, tais como encontrar os dados, índice hash é calculada apenas uma vez para se obter os dados correspondentes é recuperados muito rápido. Mysql mas não tomou como seu algoritmo de hash subjacente, que é por quê?

Considerando que não é um meio comum de recuperação de dados é encontrar o intervalo, por exemplo, a seguinte instrução SQL:

select \* from user where id \>3;

Para a declaração acima, nós queremos fazer é descobrir id> 3 de dados, que normalmente é no olhar gama. Se você usa um algoritmo de hash de índice, que vão encontrar a forma de fazê-lo? Uma idéia simples é descobrir uma vez que todos os dados são carregados na memória e, em seguida, o rastreio de dados de filtro dentro da faixa alvo na memória. Mas o âmbito deste método para encontrar demasiado volumoso, não em termos do menos eficiente.

Assim, usando um algoritmo de hash embora o índice pode ser feito rapidamente recuperar dados, mas não conseguiu encontrar o intervalo para a eficiência de dados e, portanto, não é índice hash adequada como a estrutura de dados índice Mysql subjacente.

1. Binário árvore de busca (BST)

Árvore é uma pesquisa binária para encontrar rapidamente a estrutura de dados de suporte de dados, como mostrado na figura:

Pesquisa binária complexidade de tempo árvore é O (LGN), como por acima desta árvore binária, precisamos calcular os comparativos três vezes você pode recuperar id data = 7, ao contrário de atravessar diretamente a consulta salvar metade do tempo, a partir da busca eficiência parece ser capaz de fazer a recuperação de alta velocidade. Além disso estrutura da árvore binária não pode resolver a função de pesquisa índice de intervalo hash não pode fornecê-la?

A resposta é sim. FIG observado acima, os nós folha árvore binária são dispostas sequencialmente, em ordem crescente, da esquerda para a direita, se precisamos encontrar id> 5 dados, então remover o nó e um nó 6, que pode ser uma sub-árvore direita , encontrar o intervalo pode ser considerado relativamente fácil de implementar.

Mas árvore de busca binária comum tem uma falha fatal: casos extremos, degenerado em lista linear, busca binária vai degenerar para atravessar para encontrar a complexidade de tempo reduzido para O (N), uma queda acentuada no desempenho de recuperação. Por exemplo, o seguinte neste caso, a árvore binária tem sido extremamente desequilibrado, se degenerou em uma lista ligada, a velocidade de recuperação é bastante reduzido. Neste momento, o número de cálculos necessários para obter o ID de dados = 7 mudou para a 7.

No banco de dados, os dados de incremento é uma forma muito comum, tais como chave primária de uma tabela é o id, e a chave primária é geralmente o padrão auto-incrementada, se você tomar uma estrutura de dados árvore binária, como um índice, que a descrição acima ao desequilíbrio problemas causados ​​pelo estado de busca linear do inevitável. Assim, uma pesquisa binária árvore recuperação problema simples desequilíbrio de degradação do desempenho, não pode ser usado diretamente para alcançar índice subjacente Mysql.

1. árvores AVL e árvore de vermelho-preto

Há desequilíbrio binário pesquisa árvore, de modo que os estudiosos de auto-rotação e ajustar os nós da árvore, por isso sempre manter o estado árvore binária básica equilibrada, seremos capazes de manter a árvore de busca binária ideal para encontrar o desempenho. Há árvores AVL e árvore de vermelho-preto com base nesta ideia de equilíbrio árvore binária de auto-ajuste.

Primeiro, uma breve rubro-negro árvore, que árvore é uma árvore irá ajustar automaticamente a morfologia, como quando uma árvore binária em um estado de desequilíbrio, automaticamente rubro-negro nó da árvore ea forma de árvore cor nó lateralidade ajuste, de modo que para manter o seu equilíbrio básico (complexidade de tempo é o (log n)), que irá garantir que a eficiência de pesquisa não é significativamente reduzida. Tal como a inserção de dados a partir do nó 1-7 em ordem crescente, se uma árvore de pesquisa binária ordinário degenerar em uma lista ligada, mas continuará a ajustar árvores pretas formar uma árvore, que permanece substancialmente estado de equilíbrio, como mostrado na FIG. A seguinte árvore de vermelho-preto para encontrar o id = 7 para comparar o número de nós 4, mantendo um bom binário eficiência pesquisa árvore.

árvore rubro-negra tem uma boa eficiência de pesquisa média, não havia extremo de O (n) caso, essa árvore rubro-negro como Mysql se o índice subjacente pode alcançá-lo? Na verdade, vermelho-preto árvore existem alguns problemas, observe o seguinte exemplo.

seqüência rubro-negro inserção árvore 1-7 nós, nós precisamos encontrar id = 7 é calculada 4.

1 inserida na ordem vermelho-negro árvore a 16 nós, lookup id = 16 nós para ser comparado por seis vezes. Olhe para a forma da árvore, não é quando os dados são inseridos na ordem, a forma da árvore tem sido a tendência "de direita" nele? Do ponto de vista fundamental, a árvore rubro-negra não resolve completamente a árvore de busca binária, embora esta tendência "direito" está longe de ser um binário degenerados busca de árvores em lista linear de modo exagerado, mas, basicamente, a chave primária na operador de incremento de banco de dados, geralmente a chave primária milhões de dezenas de milhões de árvore vermelho-negro, se é que existe tal um problema, olhar para o desempenho é um consumo enorme, nosso banco de dados não pode tolerar esta espera sem sentido.

Agora, considere outra árvore binária de auto-equilíbrio AVL árvore mais rigorosas. Porque a árvore AVL é uma árvore binária equilibrada absoluta, então ele consumido na forma de um ajuste de árvore binária será mais o desempenho.

árvores AVL 1-7 sequência inserida nó, o número de pesquisa do ID = 7 para o nó de comparação é três.

árvore sequência de inserção AVL 1 a 16, os nós de pesquisa id = 16 nós para ser comparado a 4. Em termos de eficiência de busca, árvore AVL velocidade de pesquisa de busca de eficiência de árvore vermelho-preto (AVL árvore é quatro vezes em comparação com árvore de vermelho-preto é de 6 comparações). A partir da forma de exibição em árvore, AVL árvore, árvore rubro-negra não existe problema "direita". Em outras palavras, um grande número inserido na ordem não leva a uma diminuição na consulta de desempenho. Isto resolve o problema da árvore de vermelho-preto fundamentalmente.

Resume a árvore vantagens AVL:

1. Encontrar um bom desempenho (O (log n)), casos extremos ineficiente procurando não existe.
2. Encontrar uma variedade pode ser alcançado, os dados de classificação.

Parece estrutura de dados árvore AVL como os dados de olhar realmente bom, mas não é adequado para a estrutura de dados em árvore índice AVL banco de dados MySQL, porque consideramos esta pergunta:

dados de consulta de banco de dados gargalo que IO de disco, se você estiver usando árvore AVL, cada um de nós árvore de nós armazena apenas uma data, primeiro disco IO só pode tirar uma carga de dados no nó de memória, e que tais inquéritos id = 7 os dados que temos para o disco IO três vezes, isto é como demorado sim. Então, precisamos projetar os índices de banco de dados em primeiro lugar considerar como reduzir o número de IO de disco possível.

Há um disco IO tem um recurso que lê os dados de dados e hora 1B 1 KB consumidos é basicamente o mesmo do disco, nós podemos de acordo com esta ideia, podemos armazenar o máximo de dados em um nó de árvore, um disco IO em dados multi-ponto carregados na memória, essa é a árvore princípio de design B, B + árvore do.

1. B-tree

A seguir B-tree, cada nó do armazenamento de chaves mais restritiva dois, um nó se mais de dois chave irá dividir automaticamente. Por exemplo, os seguintes dados armazenados na B-tree sete, só precisa verificar dois nós pode saber o ID de local específico = 7 Estes dados, que é duas vezes o disco IO pode consultar para especificar os dados melhor do que árvore AVL.

O seguinte é um B-tree lojas 16 de dados, também armazenar até 2 por chave de nó, o ID de consulta = 16 necessidade de consultar os dados comparando quatro nós, ou seja, depois de quatro IO de disco. AVL desempenho da consulta árvore e parece o mesmo.

Mas dado o disco IO ler dados e uma leitura de 100 dados consumidos tempo são basicamente os mesmos, que nossas idéias de otimização pode ser lido: tanto quanto possível em um disco IO ler mais dados na memória. Isto se reflecte directamente na estrutura da árvore é de que cada nó pode armazenar a chave pode ser aumentada.

Quando o número da chave de um limite único nó que é definido após 6, uma memória 7 dos dados B-árvores, consulta id = disco IO 7 Estes dados deve ser realizada duas vezes.

A 16 armazena dados B-tree, id query = Disk IO 7 esses dados para ser realizada duas vezes. árvore AVL em termos relativos ao número de IO de disco é reduzida a metade.

Então estrutura de dados Seleção índice de banco de dados em termos de, árvore B é uma escolha muito boa. Em resumo, árvore B como uma base de dados de índice tem as seguintes vantagens:

1. Excelente velocidade de recuperação, a complexidade de tempo: desempenho de pesquisa B-árvore é igual a O (h * log n), em que a altura h da árvore, cada nó é o número de n-chave;
2. Mínimo IO de disco, recuperação de velocidade;
3. Ele pode suportar uma variedade de pesquisa.
4. B + Tree

B-árvore e B + árvore tem que diferença vai fazer?

Primeiro, um nó B-tree nos dados armazenados, ea árvore B + armazenado em um índice (endereço), o B-árvore em um nó não pode salvar um monte de dados, mas o nó de árvore B + pode armazenar uma grande quantidade de índice, nó B + folhas armazenar todos os dados.

Em segundo lugar, o nó B + folha de árvore é uma fase de dados lista ligada utilizados em conjunto, fácil de encontrar o intervalo.

Ao comparar a árvore B e B + árvores vemos, B nó + árvore armazenar o índice da capacidade de armazenamento do nó único limitado é, um único nó pode armazenar um grande número de índice, para que toda a altura da árvore B + é reduzida, reduzindo a IO de disco. Em segundo lugar, o nó folha B + árvore é onde o armazenamento de dados real, os nós folha são conectados com uma lista ligada, a própria lista é ordenada, quando se olha para o intervalo de dados, mas também com eficiência. Assim índice Mysql utilizado é árvore B +, B + árvore na eficiência pesquisa, gama Lookup ter um desempenho muito bom.

Dois, motores InnoDB e mecanismos de alcançar myisam

Mysql subjacente mecanismo de dados como um projeto ficha, o mais comum é o motor InnoDB e motor MyISAM, os usuários podem escolher motores diferentes, como a folha de dados Mysql mecanismo subjacente de acordo com as necessidades individuais. Nós acabamos de analisar, B + árvore como a estrutura de dados do índice de Mysql é muito apropriado, mas os dados e índices no final como se organizam também precisam de algum projeto, diferente filosofia de design também levou ao surgimento InnoDB e MyISAM de cada exposição propriedades únicas.

MyISAM Embora os dados parecem muito bom desempenho, mas a transação não é suportado. Innodb principal característica é apoiar as funções de transação ACID-compliant, mas ele suporta o bloqueio em nível de linha. Mysql criar tabelas quando você pode especificar o motor, como o exemplo a seguir, especificar que a tabela MyISAM e InnoDB e user2 como o motor de dados da tabela de usuário.

Depois de executar essas duas instruções, o sistema apareceu o seguinte documento descrevendo a organização dos dois dados do motor e os índices não são os mesmos.

Depois de criar uma tabela InnoDB arquivos gerados são:

• FRM: create table
• BID: os dados dentro do arquivo de índice + mesa

Depois myisam criar uma tabela gerada arquivos têm

• FRM: create table
• MYD: mesa dentro do arquivo de dados (dados MyISAM)
• MYI: mesa dentro do arquivo de índice (índice myisam)

Do ponto de vista ficheiro resultante, a organização dos dois motores dos dados e índices subjacentes não são o mesmo, os dados do motor e MyISAM índice separados, um de um ficheiro, o qual é chamado de modo de índice não-agregadas; dados do motor e índices em Innodb o mesmo arquivo, que é chamado o modo de índice agrupado. análise ângulo destes dois motores é como confiar em estrutura de dados em árvore B + para organizar este motor para alcançar a implementação subjacente de baixo.

1. motor MyISAM aplicação (modo de índice não-agrupado)

Uma forma de realização não-agrupado índice MyISAM, isto é, os dados e o índice cai em dois ficheiros diferentes. Quando a tabela MyISAM para construir o CHAVE chave primária como para estabelecer + árvore índice B primária, os nós de folhas da árvore é o endereço físico correspondente aos dados armazenados. Depois de obter o endereço físico, você pode localizar o arquivo de dados MyISAM diretamente a registros de dados específicos.

Quando adicionar um índice para um campo, que também irá gerar um nó folha índice de árvore correspondente campo da árvore índice do campo também registra o endereço físico correspondente aos dados, e, em seguida, também tomou o endereço físico para localizar o arquivo de dados para registros de dados específicos.

1. O motor Innodb implementação subjacente (modo índice agrupado)

InnoDB é um modo de índice em cluster, assim que os dados e os índices são armazenados no mesmo ficheiro. Primeiro InnoDB cria ID chave primária como índice CHAVE B árvore + mostrado na figura esquerda abaixo, os nós de folha armazenados em B árvores + que são a chave correspondente aos dados de identificação, tais como quando realizando seleccione * de user_info onde ID = 15 Esta afirmação, InnoDB ID é consultado Zheke principal índice da chave B + árvore, para encontrar o user_name correspondente = 'Bob'.

foi construído quando a tabela InnoDB irá automaticamente construir uma boa chave ID índice de árvore principal, que é por isso que você deve especificar os requisitos Mysql chave primária quando a construção da tabela. Quando adicionar um campo para a tabela será como InnoDB árvores índice índice? Por exemplo, damos user_name deste campo é indexado, então o InnoDB criará um índice user_name B + árvore, nó user_name é armazenado na chave, os dados armazenados no nó de folha é a CHAVE chave primária. Note-se que as folhas são armazenados em KEY chave primária! Obter a chave de chave primária, o InnoDB irá para a árvore de índice de chave primária apenas principal árvore de índice de chave encontrada em user_name CHAVE encontrar os dados correspondentes.

A pergunta é: Por que InnoDB apenas no nó de folha da árvore índice de chave primária são armazenados dados específicos, mas outra árvore índice não mantém dados específicos ainda, mas quero incomodar para encontrar a chave primária e, em seguida, encontrar os dados correspondentes nas árvores índice de chave primária?

Na verdade, muito simples, porque o InnoDB precisa economizar espaço de armazenamento. Uma tabela pode ter muitos do índice, InnoDB será adicionado a cada árvore índice gerado campo de índice, se o índice de árvore para cada campo são armazenados dados específicos, esta tabela de índice torna-se muito grandes arquivos de dados (dados a redundância extrema). Do ponto de vista de economia de espaço em disco, ele não é realmente necessário para cada campo de árvores de índice são armazenados dados específicos, esta etapa parece ser "supérfluo", economizando espaço em disco enorme à custa de menos desempenho da consulta, que é muito interessante.

Quando se trata de realização características comparativas de InnoDB e MyISAM, MyISAM melhor consulta de desempenho, desde a concepção dos arquivos de dados de arquivos de índice acima também podem olhar para ver o porquê: MyISAM diretamente para o endereço físico pode ser localizado logo após o registro de dados, mas consulta InnoDB ao nó folha, ainda precisa consultar uma árvore índice de chave primária, que podem ser direcionados para dados específicos. MyISAM encontrado igual a passo sobre os dados, mas ao de duas etapas InnoDB, MyISAM curso superior desempenho da consulta.

Este artigo discute a estrutura de dados que é mais adequado para atingir o índice subjacente como mysql, e, em seguida, introduzidos os dois dados mysql clássicos subjacentes MyISAM e implementação motor InnoDB. Finalmente, para resumir o que a sua mesa quando você precisa adicionar um índice de campo que:

1. Mais frequente como o campo do índice de condições de consulta deve ser criado;
2. campo singularidade não é muito ruim para a criação de um índice sozinho, mesmo que o campo frequentemente como uma consulta;
3. campos muito atualizadas não são adequados para a criação de um índice.