9. Como adicionar índice a string
9.1 Índice de prefixo
MySQL suporta índices de prefixo. Por padrão, se você criar um índice sem especificar o comprimento do prefixo, o índice conterá a string inteira.
mysql> alter table teacher add index index1(email);
#或
mysql> alter table teacher add index index2(email(6));
Se você estiver usando index1 (ou seja, a estrutura de índice de toda a sequência de e-mail), a sequência de execução será a seguinte:
- Encontre o registro cujo valor de índice é '[email protected]' na árvore de índice index1 e obtenha o valor de ID2;
- Vá para a chave primária e encontre a linha cujo valor da chave primária é ID2, julgue se o valor de email está correto e adicione esta linha de registros ao conjunto de resultados;
- Obtenha o próximo registro na posição recém-encontrada na árvore de índice index1 e descubra que a condição email='[email protected]' não é mais atendida e o loop termina.
Durante esse processo, você só precisa recuperar os dados do índice de chave primária uma vez, para que o sistema pense que apenas uma linha foi verificada.
Se você estiver usando index2 (ou seja, estrutura de índice email(6)), a sequência de execução será a seguinte:
- Encontre registros que satisfaçam o valor do índice 'zhangs' na árvore de índice index2, e o primeiro encontrado é ID1;
- Vá para a chave primária e encontre a linha cujo valor da chave primária é ID1. Julga-se que o valor do email não é '[email protected]' e esta linha de registros é descartada;
- Obtenha o próximo registro na posição encontrada no índice2 e descubra que ele ainda é 'zhangs'. Retire o ID2, obtenha a linha inteira no índice de ID e julgue se desta vez o valor está correto. Adicione esta linha de registros ao o conjunto de resultados;
- Repita a etapa anterior até que o valor obtido em idxe2 não seja 'zhangs' e o loop termine.
Em outras palavras, usar um índice de prefixo e definir o comprimento pode economizar espaço sem adicionar muitos custos adicionais de consulta . Já falámos anteriormente sobre discriminação: quanto maior for a discriminação, melhor. Porque quanto maior a distinção, menos valores-chave duplicados.
9.2 O impacto do índice de prefixo no índice de cobertura
Conclusão:
O uso de índices de prefixo elimina a necessidade de cobrir índices para otimizar o desempenho da consulta.Este também é um fator que você precisa considerar ao escolher se deseja usar índices de prefixo.
10. Pushdown do índice
Index Condition Pushdown (ICP) é um novo recurso do MySQL 5.6. É um método de otimização que usa índices para filtrar dados na camada do mecanismo de armazenamento. O ICP pode reduzir o número de vezes que o mecanismo de armazenamento acessa a tabela base e o número de vezes que o servidor MySQL acessa o mecanismo de armazenamento.
10.1 Processo de digitalização antes e depois do uso
No processo de não usar a varredura do índice ICP:
Camada de armazenamento: apenas a linha inteira de registros correspondentes aos registros de índice que atendem às condições da chave de índice é retirada e devolvida à camada do servidor.
Camada do servidor: use a condição where subsequente para filtrar os dados retornados até que a última linha seja retornada.
O processo de uso da varredura ICP:
- camada de armazenamento:
Primeiro, determine o intervalo de registro do índice que satisfaz a condição da chave do índice e, em seguida, use o filtro de índice no índice para filtrar. Somente os registros de índice que atendem às condições do indexfilter são retornados para a tabela e toda a linha de registros é retornada para a camada do servidor. Os registros de índice que não atendem às condições do filtro de índice são descartados e não serão retornados à tabela ou camada do servidor.
- camada do servidor:
Para os dados retornados, use condições de filtro de tabela para filtragem final.
Diferença de custo antes e depois do uso. Antes do uso
, a camada de armazenamento retornava muitas linhas de registros que precisavam ser filtradas pelo filtro de índice.
Após usar o ICP, os registros que não atendiam às condições do filtro de índice eram removidos diretamente, eliminando a necessidade de eles serão devolvidos à mesa e passados para a camada do servidor.
O efeito de aceleração do ICP depende da proporção de dados filtrados pelo ICP no mecanismo de armazenamento.
10.2 Condições de utilização do PIC
Condições para usar ICP:
① Só pode ser usado para índice secundário (índice secundário)
②O valor do tipo (tipo de junção) no plano de execução exibido por explicação é intervalo, ref, eq_ref ou ref_or_null.
③ Nem todas as condições where podem ser filtradas pelo ICP. Se o campo da condição where não estiver na coluna do índice, os registros de toda a tabela ainda deverão ser lidos no servidor para filtragem where.
④ ICP pode ser usado para mecanismos de armazenamento MyISAM e InnnoDB
⑤ O MySQL versão 5.6 não suporta a função ICP de tabelas de partição e a versão 5.7 começa a suportá-la.
⑥ Quando o SQL usa índice de cobertura, o método de otimização ICP não é suportado.
11. Índice comum versus índice único
Do ponto de vista do desempenho, você deve escolher um índice exclusivo ou um índice normal? Qual é a base para a seleção?
Suponha que tenhamos uma tabela com a coluna de chave primária como ID. Há um campo k na tabela e um índice em k. Suponha que os valores no campo k não sejam repetidos. A instrução de criação de tabela para esta tabela é:
mysql> create table test(
id int primary key,
k int not null,
name varchar(16),
index (k)
)engine=InnoDB;
Os valores (ID,k) de R1~R5 na tabela são (100,1), (200,2), (300,3), (500,5) e (600,6) respectivamente.
11.1 Processo de consulta
Suponha que a instrução para executar a consulta seja select id from test where k=5.
- Para um índice normal, depois de encontrar o primeiro registro (5.500) que atende à condição, você precisa encontrar o próximo registro até encontrar o primeiro registro que não atende à condição k=5.
- Para um índice exclusivo, como o índice define exclusividade, a pesquisa será interrompida após o primeiro registro que atender às condições ser encontrado.
- Então, qual é a diferença de desempenho causada por essa diferença? A resposta é, minimamente.
11.2 Processo de atualização
Para ilustrar o impacto dos índices comuns e dos índices exclusivos no desempenho da instrução de atualização, vamos apresentar o buffer de alteração.
Quando uma página de dados precisa ser atualizada, se a página de dados estiver na memória, ela será atualizada diretamente. Se a página de dados ainda não estiver na memória, o InooDB armazenará
essas operações de atualização em cache no buffer de alteração sem afetar a consistência dos dados. não há necessidade
de ler esta página de dados do disco. Quando a próxima consulta precisar acessar esta página de dados, leia a página de dados na memória e execute as
operações relacionadas a esta página no buffer de alteração. Desta forma, a exatidão da lógica dos dados pode ser garantida.
O processo de aplicação das operações no buffer de alteração à página de dados original e obtenção dos resultados mais recentes é chamado de mesclagem. Além de acionar a mesclagem ao acessar esta página de dados
, o sistema possui threads em segundo plano que se mesclam regularmente. Durante o encerramento normal do banco de dados, a
operação de mesclagem também será executada.
Se a operação de atualização puder ser gravada primeiro no buffer de alteração para reduzir as leituras do disco, a velocidade de execução da instrução será significativamente melhorada. Além disso,
a leitura de dados na memória requer a ocupação do buffer pool, portanto, esse método também pode evitar a ocupação de memória e melhorar a utilização da memória.
O buffer de alteração não pode ser usado para atualizar o índice exclusivo. Na verdade, apenas índices comuns podem ser usados.
12. Outras estratégias de otimização de consultas
12.1 A diferença entre EXISTS e IN
Não entendo muito bem em que caso EXISTS deve ser usado e em que caso IN deve ser usado. O critério de seleção é baseado na possibilidade de uso do índice da tabela?
12.2 Eficiência de COUNT(*) e COUNT (campos específicos)
Pergunta: Existem três maneiras de contar o número de linhas em uma tabela de dados no MySQL: SELECT COUNT(*), SELECT COUNT(1) e
SELECT COUNT (campos específicos).Qual é a eficiência da consulta entre esses três métodos?
12.3 Sobre SELECIONAR(*)
Em consultas de tabela, recomenda-se especificar os campos. Não usar * como lista de campos da consulta. Recomenda-se usar a consulta SELECT <lista de campos>. Razões:
① Durante o processo de análise, o MySQL converterá "*" em todos os nomes de colunas em ordem, consultando o dicionário de dados, o que consumirá muito recursos e tempo
.
② O índice de cobertura não pode ser usado
12.4 Impacto do LIMIT 1 na otimização
Destina-se a instruções SQL que verificam a tabela inteira. Se você tiver certeza de que há apenas um conjunto de resultados, adicionar LIMIT 1 não continuará a verificação quando um resultado for encontrado, o que acelerará a consulta.
Se a tabela de dados tiver estabelecido um índice exclusivo para o campo, você poderá consultar através do índice. Se a tabela inteira não for verificada, não há necessidade de adicionar
LIMIT 1.
12.5 Use mais COMMIT
Sempre que possível, utilize o COMMIT ao máximo no programa, para que o desempenho do programa seja melhorado e a demanda seja
reduzida devido aos recursos liberados pelo COMMIT.
Recursos liberados pelo COMMIT:
- Informações sobre o segmento de reversão usado para recuperar dados
- Bloqueio adquirido por instrução do programa
- Espaço no buffer de log de refazer/desfazer
- Gerenciar gastos internos nos 3 recursos acima