none
Hash Match melhorar RRS feed

  • Pergunta

  • Como "evitar" esse hash match? Ta causando 70% do custo da consulta...

    De resto ta tudo certo, tudo dando seek, etc...

    Só isso que ainda está causando uma lentidão...

    Como faço pra melhorar isso?


    Aprendiz
    sexta-feira, 15 de julho de 2011 18:18

Respostas

  • Bom Dia,

    Seu vermos o plano é realmente impossível darmos sugestões. O HASH Match é uma espécie de "encontro de ponteiros" muito semelhante a um JOIN. Normalmente está associado a situações onde dois índices simples ajudam a encontrar os registros, mas onde os dois sozinhos não são suficientes e por isso precisam combinar-se para encontrar as referências comuns. Ex:

    - Uma tabela de lançamentos contábeis possui 50 milhões de registros
    - Ela possui um índice sobre a coluna DataLancamento e um outro índice sobre a coluna CPF
    - A busca deseja recuperar os registros onde o CPF é 788039192-54 na data 17/01/2011 (0,25% dos registros)
    - Se usarmos o índice do CPF, ele trás 4% da tabela
    - Se usarmos o índice da Data, ele trás 3,8% da tabela

    Basicamente teríamos duas opções.

    A primeira opção seria usar o índice CPF, retornar 4% da tabela, avaliar os registros que sobraram e aplicar um filtro onde a Data seria 17/01/2011
    A segunda seria usar o índice Data, retornar 3,8% da tabela, avaliar os registros que sobraram e aplicar um filtro onde o CPF seria 788039192-54

    Entretanto, se um índice é composto de uma coluna e um ponteiro, há uma terceira opção mais interessante. Usa-se o índice CPF e localiza-se os ponteiros que apontam para o CPF 788039192-54 e usa-se o índice Data e localiza-se os ponteiros que apontam para a data 17/01/2011. Posteriormente cruza-se os ponteiros de um índice com os ponteiros do outro índice e aí localiza-se os registros que obedecem as duas condições. Essa junção dos ponteiros é o HASH MATCH.

    Especificamente nesse exemplo, o HASH MATCH poderia ser eliminado se houvesse um índice composto com as colunas Data e CPF (Data na frente, pois, é mais seletivo nesse exemplo). Assim, com um único índice já localizaríamos os ponteiros evitando o HASH MATCH nesse hipotético exemplo. Entretanto, sem ver o seu plano, não sei se a explicação aplica-se.

    Adicionalmente, 70% não significa nada sem um contexto. Você pode resolver o HASH MATCH e a consulta passar a gastar muito recurso em outra tarefa (como um SORT por exemplo) ou até dividir igualmente o peso (10% para cada tarefa em um plano de 10 tarefas). Isso não significa que a consulta está ou não otimizada. O ideal seria observar também outros itens como o STATISTICS I/O para um diagnóstico mais apurado.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    domingo, 17 de julho de 2011 13:30

Todas as Respostas

  • Edivaldo, pode postar a sua consulta?
    Roberson Ferreira - Database Developer
    Acesse: www.robersonferreira.com.br

    Se esta sugestão for útil, por favor, classifique-a como útil.
    Se ela lhe ajudar a resolver o problema, por favor, marque-a como Resposta.

    sexta-feira, 15 de julho de 2011 22:11
    Moderador
  • Edivaldo,

    Inicialmente você poderia explicar que tipo de query esta realizando? Normalmente o SQL Server utilizar o Operador Hash Match em consultas que trabalham com colunas computadas.

    Por acaso você esta utilizando algum tipo de agrupamento ou funções de agregação de dados?


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]
    sábado, 16 de julho de 2011 15:15
  • Bom Dia,

    Seu vermos o plano é realmente impossível darmos sugestões. O HASH Match é uma espécie de "encontro de ponteiros" muito semelhante a um JOIN. Normalmente está associado a situações onde dois índices simples ajudam a encontrar os registros, mas onde os dois sozinhos não são suficientes e por isso precisam combinar-se para encontrar as referências comuns. Ex:

    - Uma tabela de lançamentos contábeis possui 50 milhões de registros
    - Ela possui um índice sobre a coluna DataLancamento e um outro índice sobre a coluna CPF
    - A busca deseja recuperar os registros onde o CPF é 788039192-54 na data 17/01/2011 (0,25% dos registros)
    - Se usarmos o índice do CPF, ele trás 4% da tabela
    - Se usarmos o índice da Data, ele trás 3,8% da tabela

    Basicamente teríamos duas opções.

    A primeira opção seria usar o índice CPF, retornar 4% da tabela, avaliar os registros que sobraram e aplicar um filtro onde a Data seria 17/01/2011
    A segunda seria usar o índice Data, retornar 3,8% da tabela, avaliar os registros que sobraram e aplicar um filtro onde o CPF seria 788039192-54

    Entretanto, se um índice é composto de uma coluna e um ponteiro, há uma terceira opção mais interessante. Usa-se o índice CPF e localiza-se os ponteiros que apontam para o CPF 788039192-54 e usa-se o índice Data e localiza-se os ponteiros que apontam para a data 17/01/2011. Posteriormente cruza-se os ponteiros de um índice com os ponteiros do outro índice e aí localiza-se os registros que obedecem as duas condições. Essa junção dos ponteiros é o HASH MATCH.

    Especificamente nesse exemplo, o HASH MATCH poderia ser eliminado se houvesse um índice composto com as colunas Data e CPF (Data na frente, pois, é mais seletivo nesse exemplo). Assim, com um único índice já localizaríamos os ponteiros evitando o HASH MATCH nesse hipotético exemplo. Entretanto, sem ver o seu plano, não sei se a explicação aplica-se.

    Adicionalmente, 70% não significa nada sem um contexto. Você pode resolver o HASH MATCH e a consulta passar a gastar muito recurso em outra tarefa (como um SORT por exemplo) ou até dividir igualmente o peso (10% para cada tarefa em um plano de 10 tarefas). Isso não significa que a consulta está ou não otimizada. O ideal seria observar também outros itens como o STATISTICS I/O para um diagnóstico mais apurado.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    domingo, 17 de julho de 2011 13:30
  • Bom dia,

    Acho que não tem como eu enviar o plano de execução aqui, né?

    é um select simples, faz 6 joins, e retorna 5 dados, sem nenhuma função nem nada.

     

    Criei um indice pra uma tabela, e parou de fazer o hash join, isso eu forçando utilizar esse indice.

    o custo dessa consulta dentro do meu processo, era de 33%, forçando o indice mudou pra 25%.

     

    Sem forçar o indice, ele começa utilizar esse indice novo que eu criei, mas mesmo assim ele faz o hash join, e retorna pra 33% o custo da consulta no lote. =s

    Isso realmente não entendi.

     

    Se eu precisar de enviar o plano de execução como faço?

     

    abrass, obrigado.


    Aprendiz
    segunda-feira, 18 de julho de 2011 12:34
  • Olá Edivaldo,

    Você pode compartilhar em algum file server na NET ou algo assim (imageshack por exemplo).

    Só lembrando que HASH MATCH e HASH JOIN são coisas diferentes. O que estamos tendo no momento ? HASH MATCH ou HASH JOIN ?

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    segunda-feira, 18 de julho de 2011 13:23