Carregando ...
Desculpe, ocorreu um erro ao carregar o conteúdo.

33223Re: [mssql-l] Melhores práticas - melhorando o scri pt

Expandir mensagens
  • Vitor Bueno
    6 de dez de 2016
      Wolney/André, agradeço muito a atenção.



      A ideia é esta mesmo, inserção de novos dados na tabela (com chave composta) de maneira que não insira dados já existentes.

      Só fazendo um clareamento de idéias, o uso do convert foi uma engenharia alternativa para montar uma chave única e pesquisar na tabela detalhe, feita de bate-pronto pois não estava conseguindo fazer uso do exists.

      Estou fazendo outro teste aqui que é a criação de uma coluna calculada automaticamente montando o que atualmente está com o convert. Isto me eliminaria o SEEK e permitiria, sendo uma coluna física, criar índice para melhorar a pesquisa. Vou traçar num banco de teste e comparar as soluções para ver o que melhor traz de desempenho.

      Aproveitando a deixa, vamos por partes:



      1. Fiz alguns testes para a solução do Wolney, com plano de execução, o seguinte retorno:

      Imagem inline 1
      Tempo de Execução do Cliente 15:44:03
      Estatísticas do Perfil da Consulta
        Número de instruções INSERT, DELETE e UPDATE 2 2.0000
        Linhas afetadas pelas instruções INSERT, DELETE ou UPDATE 2 2.0000
        Número de instruções SELECT 3 3.0000
        Linhas retornadas pelas instruções SELECT 3 3.0000
        Número de transações 2 2.0000
      Estatísticas de Rede
        Numero de viagens de ida e volta ao servidor 3 3.0000
        Pacotes TDS enviados do cliente 3 3.0000
        Pacotes TDS recebidos do servidor 9 9.0000
        Bytes enviados do cliente 1684 1684.0000
        Bytes recebidos do servidor 23184 23184.0000
      Estatísticas de Tempo
        Tempo de processamento do cliente 31 31.0000
        Tempo total de execução 62 62.0000
        Tempo de espera em respostas do servidor 31 31.0000






      2. Já a lógica do André, adaptada ao mesmo banco de teste, retornou o seguinte:


      Imagem inline 3


      Tempo de Execução do Cliente 15:49:28 15:49:22 15:49:03 15:48:55
      Estatísticas do Perfil da Consulta
        Número de instruções INSERT, DELETE e UPDATE 2 0 0 0 0.5000
        Linhas afetadas pelas instruções INSERT, DELETE ou UPDATE 5 0 0 0 1.2500
        Número de instruções SELECT 3 0 2 0 1.2500
        Linhas retornadas pelas instruções SELECT 3 0 2 0 1.2500
        Número de transações 2 0 0 0 0.5000
      Estatísticas de Rede
        Numero de viagens de ida e volta ao servidor 3 3 3 3 3.0000
        Pacotes TDS enviados do cliente 3 3 3 3 3.0000
        Pacotes TDS recebidos do servidor 7 3 3 3 4.0000
        Bytes enviados do cliente 1270 1270 1294 1286 1280.0000
        Bytes recebidos do servidor 19752 174 202 164 5073.0000
      Estatísticas de Tempo
        Tempo de processamento do cliente 31 0 15 0 11.5000
        Tempo total de execução 46 15 15 15 22.7500
        Tempo de espera em respostas do servidor 15 15 0 15 11.2500



      Esta solução do me economizou 2 filtros e 1 compute escalar, mas me retornou mais avaliações.






      3. Fiz mais um teste com a proposta do wolney, removendo os withs e executando no mesmo select, o que aumentou uma avaliação, usou 1 filtro a menos no plano de execução e retornou:


      Imagem inline 2


      Tempo de Execução do Cliente 16:06:54 15:44:03
      Estatísticas do Perfil da Consulta
        Número de instruções INSERT, DELETE e UPDATE 2 2 2.0000
        Linhas afetadas pelas instruções INSERT, DELETE ou UPDATE 0 2 1.0000
        Número de instruções SELECT 3 3 3.0000
        Linhas retornadas pelas instruções SELECT 3 3 3.0000
        Número de transações 2 2 2.0000
      Estatísticas de Rede
        Numero de viagens de ida e volta ao servidor 5 3 4.0000
        Pacotes TDS enviados do cliente 5 3 4.0000
        Pacotes TDS recebidos do servidor 10 9 9.5000
        Bytes enviados do cliente 1816 1684 1750.0000
        Bytes recebidos do servidor 21977 23184 22580.5000
      Estatísticas de Tempo
        Tempo de processamento do cliente 15 31 23.0000
        Tempo total de execução 46 62 54.0000
        Tempo de espera em respostas do servidor 31 31 31.0000


      Para efeito de leitura de código, me parece melhor fazer o uso do with, embora, se considerar tempo de execução, este foi ligeiramente menor, certo?








      4. Este é o plano de execução da rotina como ela está (com o convert)

      Imagem inline 4
      Tempo de Execução do Cliente 16:15:58 16:15:50
      Estatísticas do Perfil da Consulta
        Número de instruções INSERT, DELETE e UPDATE 2 0 1.0000
        Linhas afetadas pelas instruções INSERT, DELETE ou UPDATE 0 0 0.0000
        Número de instruções SELECT 2 1 1.5000
        Linhas retornadas pelas instruções SELECT 2 1 1.5000
        Número de transações 2 0 1.0000
      Estatísticas de Rede
        Numero de viagens de ida e volta ao servidor 3 3 3.0000
        Pacotes TDS enviados do cliente 3 3 3.0000
        Pacotes TDS recebidos do servidor 9 3 6.0000
        Bytes enviados do cliente 1170 1178 1174.0000
        Bytes recebidos do servidor 24737 189 12463.0000
      Estatísticas de Tempo
        Tempo de processamento do cliente 16 0 8.0000
        Tempo total de execução 31 0 15.5000
        Tempo de espera em respostas do servidor 15 0 7.5000












      Gostei bastante desta lógica do andré, eu estava bobeando na relação do where da subquery.




      Como que eu posso ponderar qual é melhor em relação a desempenho, considero o tempo total de execução <11.5 da lógica do andré> ?


       



      Grato pelas elucidações.

      Vitor


    • Mostrar todas as 6 mensagens neste tópico