Noções básicas de mysql quatro: consulta lenta e otimização de sql

9 Quais são os conteúdos específicos do plano de execução do MySQL? O que o mysql explica?

Quais são os conteúdos específicos do plano de execução do MySQL? explicar

10 Como localizar uma instrução de consulta lenta SQL

10.1 Posicionamento

Para a maioria dos sistemas de gerenciamento de banco de dados relacional (RDBMS), existem ferramentas e técnicas correspondentes para identificar consultas lentas:

1. registro :

   • MySQL : O log de consulta lenta ( ) pode ser habilitado slow_query_logpara registrar consultas cujo tempo de execução excede um determinado limite.
   • PostgreSQL : Ao definir log_min_duration_statementparâmetros, você pode fazer com que consultas cujo tempo de execução exceda um determinado limite sejam registradas no log.
   • SQL Server : use o SQL Server Profiler para capturar consultas lentas.
   • Oracle : Use relatórios AWR (Automatic Workload Repository) e ADDM (Automatic Database Diagnostic Monitoring) para identificar consultas lentas.

2. Ferramentas de desempenho e monitoramento : a maioria dos RDBMSs fornece ferramentas para visualizar estatísticas de desempenho para consultas em execução ou consultas executadas recentemente. Por exemplo, o MySQL possui SHOW PROCESSLISTe o PostgreSQL possui pg_stat_statementsmódulos.

Concluindo, a inspeção e análise regulares do desempenho do banco de dados é a chave para garantir sua operação saudável. Por meio dos métodos e ferramentas acima, consultas lentas podem ser identificadas e otimizadas com eficácia.

10.2 Como analisar a instrução de consulta lenta localizada e visualizar o plano de análise

3. Comando EXPLAIN : Quando você tem uma instrução SQL que é suspeita de ser uma consulta lenta, use o comando EXPLAIN (ou em alguns bancos de dados, como o SQL Server, use) EXPLAIN PLANpara visualizar o plano de execução da consulta. Isso pode ajudá-lo a entender por que sua consulta está lenta e fornecer dicas para otimizá-la.

10.3 Como otimizar instruções SQL

A otimização SQL é um tema muito aprofundado, envolvendo diversas técnicas e estratégias. Aqui estão algumas estratégias comuns de otimização de SQL:

1. Uso adequado de índices :

   • Crie índices para colunas consultadas com frequência e colunas na cláusula WHERE.
   • Evite usar funções ou cálculos em colunas, pois podem inutilizar os índices.
   • Use índices compostos para cobrir consultas.

2. Evite varreduras completas da tabela :

   • Isto é conseguido usando um índice na cláusula WHERE.
   • Considere consultas que precisam verificar apenas parte dos dados, em vez de toda a tabela.

3. Otimize a estrutura da consulta :

   • Reduza o número de colunas solicitadas na cláusula SELECT para selecionar apenas as colunas que você realmente precisa.
   • Evite usar SELECT *a menos que você realmente precise de todas as colunas da tabela.
   • Use JOINs em vez de subconsultas, quando apropriado.

4. Otimize JOINs :

   • Use índices em condições JOIN.
   • Reduza o número de JOINs e utilize-os somente quando necessário.
   • Use EXPLAIN para analisar operações JOIN.

5. Use o tipo de dados apropriado :

   • Usar o tipo de dados mais apropriado pode reduzir o armazenamento e aumentar a velocidade da consulta.
   • Por exemplo, use INT em vez de VARCHAR para armazenar números inteiros.

6. Otimize a estrutura do banco de dados :

   • Normalize o banco de dados para reduzir a redundância de dados.
   • Use a desnormalização quando necessário para melhorar o desempenho da consulta.

7. Subconsulta otimizada :

   • Substitua subconsultas por JOINs sempre que possível.
   • Em alguns casos, as subconsultas podem ser mais eficientes, mas geralmente os JOINs são mais rápidos.

8. Use partições :

   • Divida tabelas grandes em partes menores e mais gerenciáveis ​​com base nos valores de determinadas colunas.

9. Limite o conjunto de resultados :

   • Use LIMIT para reduzir o tamanho do conjunto de resultados, especialmente quando apenas alguns dos resultados são de interesse.

10. Otimizar mecanismo de armazenamento :

• Escolha um mecanismo de armazenamento apropriado com base nas necessidades do seu aplicativo (por exemplo, leitura ou gravação intensiva).

11. Manutenção regular :

• É executado periodicamente OPTIMIZE TABLEpara organizar dados e recuperar espaço não utilizado.
• Atualize as estatísticas para ajudar o otimizador de consultas a tomar melhores decisões.

12. Usar cache :

• Aproveite o cache de consulta do MySQL.
• Use uma solução de cache externo, como Redis ou Memcached.

13. Evite usar determinadas funções e operações SQL de alta sobrecarga , como pesquisas LIKE, especialmente com curingas iniciais.

14. Avalie e possivelmente reescreva consultas lentas :

• Use o log de consultas lentas para descobrir quais consultas precisam de otimização.
• Use EXPLAINpara visualizar o plano de execução de uma consulta e identificar gargalos.

Estas são apenas algumas maneiras comuns de otimizar o SQL. Na prática, cada cenário de banco de dados e aplicação pode exigir uma estratégia de otimização específica.

11 Se houver uma grande quantidade de dados em uma tabela e você consultar um registro que não está no banco de dados e descobrir que nenhum deles corresponde, como otimizá-lo neste momento? Claro, isso não significa necessariamente usar o MySQL para otimizar, mas também pode significar usar outras ferramentas para otimizar.

Ao consultar registros que não existem em uma tabela grande, a chave para a otimização é reduzir a quantidade de dados que devem ser verificados. Aqui estão algumas maneiras de otimizar esse tipo de consulta:

1. Crie índices adequados :

   • Certifique-se de que os campos consultados estejam indexados para que o banco de dados possa pesquisar rapidamente os dados em vez de fazer uma varredura completa da tabela.
   • Use EXPLAINo comando para visualizar o plano de execução da consulta para confirmar se o índice é usado.

2. Partição do banco de dados :

   • Para tabelas muito grandes, considere usar partições de banco de dados. Dessa forma, as consultas só precisam pesquisar uma ou algumas partições relevantes, em vez de pesquisar a tabela inteira.

3. Resumo dos dados :

   • Para campos consultados com frequência, um resumo (como um hash) pode ser calculado e armazenado em uma coluna ou tabela separada.
   • Ao consultar valores que não estão no banco de dados, apenas o resumo precisa ser verificado e não os dados reais.

4. Use um mecanismo de pesquisa externo :

   • Para necessidades de pesquisa complexas, ferramentas de pesquisa de texto completo, como Elasticsearch ou Solr, podem ser usadas. Essas ferramentas são muito eficazes para encontrar dados rapidamente.

5. Use filtros Bloom :

   • Um filtro Bloom é uma estrutura de dados que pode verificar de forma rápida e eficiente se um elemento está em uma coleção.
   • Use um filtro Bloom para fazer uma verificação rápida antes de consultar o banco de dados se o filtro indicar que o registro pode existir.

6. Reduzir dados :

   • Arquive ou exclua periodicamente dados que não são mais necessários para manter o tamanho da tabela dentro de um intervalo gerenciável.

7. Usar cache :

   • Se você consulta determinados conjuntos de dados com frequência, considere usar uma solução de cache, como Redis ou Memcached, para armazenar os resultados em cache. Dessa forma, para consultas comuns, você pode verificar primeiro o cache.

8. Otimização de hardware e configuração :

   • Certifique-se de que a configuração do hardware atenda aos requisitos, como uso de SSD, aumento de RAM, otimização de rede, etc.
   • Para bancos de dados, considere aumentar o tamanho do buffer, ajustar o cache de consulta, etc., para melhorar o desempenho.

9. Estratégia da camada de aplicação :

   • Se possível, tente fazer algum pré-processamento ou verificação na camada de aplicação para reduzir consultas desnecessárias.
   • Por exemplo, use um cache de aplicativo, mantenha algumas estruturas de dados para pesquisas rápidas, etc.

10. Considere a estratégia para armazenamento de dados :

    • Por exemplo, para tabelas que são consultadas com pouca frequência, mas que possuem uma grande quantidade de dados, você pode considerar o uso de armazenamento colunar (como Apache Parquet) em vez do armazenamento de linha tradicional.

Em geral, a otimização de consultas para registos que não existem em tabelas grandes requer uma compreensão profunda das suas necessidades e dados específicos. Diferentes estratégias e tecnologias têm seus cenários aplicáveis, por isso geralmente é necessário combinar vários métodos para obter o melhor desempenho.

11.1 Estabelecer índices apropriados Por que ainda é recomendado estabelecer índices apropriados no caso de tabelas grandes? Porque se você usar uma chave primária inexistente para consultar, você usará o índice? ou varredura completa da tabela

Se você consultar com uma chave primária que não existe, o banco de dados usará o índice da chave primária em vez de fazer uma varredura completa da tabela.

Os índices de chave primária (em muitos bancos de dados, as chaves primárias são exclusivas por padrão e indexadas) são projetados para pesquisa rápida de registros. Quando você faz uma consulta usando um valor de chave primária, o banco de dados procura esse índice mesmo que o registro não exista. Devido ao design da estrutura do índice (como árvore B ou índice hash), o banco de dados pode determinar rapidamente se existe um registro sem verificar a tabela inteira.

Portanto, para consultas de chave primária inexistentes, o banco de dados determinará muito rapidamente que não há registros correspondentes e retornará os resultados rapidamente, sem realizar uma verificação completa da tabela .

11.2 Por que outras medidas de otimização precisam ser tomadas após a construção do índice para reduzir significativamente o número de IOs de disco?

Resposta: Como uma tabela grande pode ter dezenas de milhões de dados, a altura de sua árvore de índice pode estar entre três e quatro camadas e o número de E/S de disco é cerca de quatro a cinco vezes, o que também consome muito tempo.

11.3 Por que o particionamento de banco de dados ajuda a evitar varreduras completas de tabelas? Se você usar partições para consultar dados que não existem, você consultará os índices B+ de todas as partições?

Ao usar o particionamento de banco de dados, as operações de consulta evitam, tanto quanto possível, a varredura de todas as partições. Se a condição de consulta contiver informações de chave de partição, o sistema de banco de dados normalmente operará apenas na partição relevante. Entretanto, se as condições da consulta não contiverem informações que possam localizar uma partição específica, a consulta poderá precisar ser executada em todas as partições. Portanto, para consultas sobre dados inexistentes, se a condição não possuir uma chave de partição, é de fato possível consultar os índices B+ de todas as partições.

Por exemplo, se a data for usada como condição para particionamento de intervalo, ao consultar uma data que não existe na tabela, apenas uma partição precisa ser consultada. Por exemplo, a primeira partição armazena 2021-1-1~2022-1 - 1, a segunda partição armazena dados entre 2022-1-1 e 2023-1-1, mas ao consultar um dado com data de 2022-8-8, não importa se a data existe ou não, o Somente a segunda partição será consultado, não o primeiro.

11.4 Resumo dos dados: significa extrair separadamente os campos consultados com frequência, formar um valor hash e armazená-los e, em seguida, calcular o valor hash do campo de consulta antes de consultar para ver se há uma correspondência. Em caso afirmativo, vá para o banco de dados mysql para consulta. Se não tiver não pergunte, certo?

Sim, você entendeu corretamente. O objetivo do resumo de dados é fornecer um mecanismo rápido para verificar se é provável que exista um valor no banco de dados sem consultar diretamente os dados brutos.

Esta abordagem é baseada nas propriedades das funções hash. As funções hash convertem dados de entrada (como strings ou números) em uma string de números de comprimento fixo (valor hash). Se os valores hash de dois valores de entrada forem diferentes, os dois valores de entrada deverão ser diferentes. No entanto, se dois valores de entrada diferentes produzem o mesmo valor de hash, isso é chamado de "colisão de hash". Embora as colisões sejam possíveis, na prática, a probabilidade de uma função hash bem projetada produzir uma colisão é muito baixa.

Veja como usá-lo neste cenário:

1. Para campos consultados com frequência, calcule seu hash e armazene-o em uma coluna ou tabela separada.
2. Quando um valor específico precisa ser consultado, o valor hash do valor é calculado primeiro.
3. Consulte esse valor hash onde ele está armazenado. Se o valor hash não existir, então o valor original certamente também não existe nos dados originais, portanto não há necessidade de consultar os dados originais.
4. Se o hash existir, os dados originais poderão ser consultados posteriormente para determinar a correspondência real (já que pode haver uma colisão de hash).

Esta estratégia pode acelerar significativamente a consulta em alguns cenários, especialmente quando a quantidade de dados brutos é muito grande ou a operação de consulta é muito frequente. No entanto, observe também que essa abordagem adiciona complexidade de armazenamento (devido ao armazenamento adicional do valor hash) e alguma sobrecarga computacional adicional (devido à necessidade de calcular o valor hash).

11.5 Usando o filtro Bloom, este método é particularmente semelhante ao resumo de dados mencionado acima?

Você está certo, os filtros Bloom funcionam de maneira muito semelhante aos resumos de índice que mencionei anteriormente. Ambos são usados ​​para determinar rapidamente se há probabilidade de existir dados sem armazenamento desnecessário ou pesquisas de banco de dados. No entanto, um filtro Bloom tem a propriedade de poder produzir falsos positivos (acreditar falsamente que um elemento existe), mas não falsos negativos (acreditar falsamente que um elemento não existe). O uso de filtros Bloom pode melhorar muito a eficiência da consulta, especialmente em cenários de big data.

11.6 Por que o uso de mecanismos de busca como o ES pode acelerar as consultas?

Regras de uso
do ES Claro. Tanto o Elasticsearch quanto o Apache Solr são construídos sobre o Lucene e são usados ​​principalmente para pesquisa de texto completo, mas também são frequentemente usados ​​como ferramentas de pesquisa e análise para big data. Aqui estão os principais motivos pelos quais eles trabalham de forma eficiente com grandes conjuntos de dados e retornam resultados de consulta rapidamente:

1. Índice invertido :

   • Esta é a principal razão pela qual o Lucene (e por extensão o Elasticsearch e o Solr) são tão rápidos de consultar. Em termos simples, um índice invertido é um mapeamento de palavras extraídas de um documento para o documento em que estão contidas. Quando um usuário consulta uma palavra ou frase, o mecanismo de busca só precisa encontrar a entrada da palavra no índice invertido e, em seguida, localizar rapidamente todos os documentos que contêm a palavra, sem digitalizar cada documento.

2. Fragmentação e processamento paralelo :

   • Tanto o Elasticsearch quanto o Solr oferecem suporte à divisão de dados em partes, ou fragmentos, que podem ser distribuídos entre vários nós. Quando as consultas são emitidas, elas podem ser executadas em paralelo em vários fragmentos, acelerando bastante o processo de consulta. Além disso, esse mecanismo de fragmentação oferece alta disponibilidade e tolerância a falhas.

3. Indexação quase em tempo real :

   • Quando os dados são unidos ao Elasticsearch ou Solr, eles são rapidamente indexados e prontos para consulta, o que garante que os dados sejam sempre consultáveis, mesmo que tenham acabado de ser unidos.

4. Armazenamento compactado e otimizado :

   • Lucene usa várias técnicas para compactar seus índices para reduzir o espaço de armazenamento e acelerar as consultas.

5. Mecanismo de cache :

   • Tanto o Elasticsearch quanto o Solr usam vários caches (como cache de filtro, cache de consulta, etc.) para reduzir cálculos repetidos e acelerar o tempo de resposta de consultas comuns.

6. Otimização de consulta :

   • Por exemplo, quando você consulta vários termos, as ferramentas podem consultar primeiro o termo menos comum porque restringe o conjunto de resultados mais rapidamente.

Portanto, quando você consulta um registro que não existe, devido ao índice invertido e outras otimizações, o mecanismo de busca pode determinar rapidamente que o registro não existe sem uma varredura completa da tabela.

Essas propriedades tornam o Elasticsearch e o Solr ferramentas ideais para pesquisa e análise rápidas em grandes conjuntos de dados. No entanto, como qualquer escolha tecnológica, nem sempre são a melhor solução. A decisão de utilizar estas ferramentas deve ser baseada nas necessidades específicas da aplicação.

11.7 Reduza os dados : arquive ou exclua regularmente os dados que não são mais necessários e mantenha o tamanho da tabela dentro de um intervalo gerenciável. É adequado para arquivamento regular, como a lista de mercadorias seckill?

Para a tabela de produtos de venda relâmpago, esse tipo de tabela geralmente contém alguns dados expirados ou que não são mais usados, porque a atividade de venda relâmpago começa e termina dentro de um horário específico. Arquivar ou excluir esses dados regularmente é de fato uma boa estratégia. Arquivar dados que não estão mais ativos, mas que podem precisar ser referenciados no futuro (por exemplo, para analisar tendências históricas ou satisfazer requisitos de auditoria), enquanto exclui dados que realmente não são mais necessários, preserva a eficiência da tabela e reduz a sobrecarga de armazenamento.