Por que não é indicado usarmos + em relacionamentos no SQL Server

Hoje vou trazer uma dica para otimizar algumas queries SQL.

Recentemente houve uma pergunta no Discord, sobre performance de uma query no Protheus, onde ela demorava muito para ser gerada.

Então eu lembrei, que em um cliente que eu atendia onde era TMS o módulo, aconteceu isso comigo algumas vezes.

Basicamente, a questão é que no relacionamento entre duas tabelas, estavam usando uma concatenação de strings, por exemplo:

C6_FILIAL + C6_NUM + C6_ITEM = C9_FILIAL + C9_NUM + C9_ITEM

E isso, causa no banco um processamento maior do que o esperado, pois pensem comigo, se ambas as tabelas tiverem milhares ou milhões de linhas. Agora imagina o banco de dados, tendo que concatenar todas as linhas da tabela 1 (no nosso exemplo SC6), depois concatenar todas as linhas da tabela 2 (no nosso exemplo SC9), e por último, após ambas as expressões, ainda fazer a comparação, e trazer só o que bate. O SQL vai ficar processando um tempinho.

Seria o mesmo que você chegar numa biblioteca e falar, “Você tem o livro Herman Melville B00K1MR7D0 Carlos Heitor Cony Moby Dick?”. Muito provavelmente o bibliotecário vai te olhar espantado por alguns segundos até entender a pergunta.

Ah Daniel, mas então como eu poderia solucionar ou melhorar a questão? Simples jovens, ao invés de concatenar os campos, você faz a comparação direta entre eles, por exemplo:

C6_FILIAL = C9_FILIAL AND C6_NUM = C9_NUM AND C6_ITEM = C9_ITEM

Dessa forma, não iremos fazer o SQL perder performance concatenando os campos e depois fazendo a comparação. Como a comparação é direta campo a campo, é muito mais rápido.

Trazendo para o exemplo da biblioteca, seria o mesmo que você chegar e falar, “Você tem o livro Moby Dick escrito por Herman Melville na tradução do Carlos Heitor Cony com o ASIN de código B00K1MR7D0?”. A expressão fica mais fácil de ser interpretada, separando as sentenças e provavelmente o bibliotecário encontrará mais rápido o livro.

Pessoal, ressalto que não sou especialista em Tuning, e que o artigo acima foi montado em cima de testes que realizei em alguns clientes. Achei dois links de referência sobre o assunto no Google, vou deixar abaixo.

Bom pessoal, por hoje é só.

Abraços e até a próxima.

Dan (Daniel Atilio)
Cristão de ramificação protestante. Especialista em Engenharia de Software pela FIB, graduado em Banco de Dados pela FATEC Bauru e técnico em informática pelo CTI da Unesp. Entusiasta de soluções Open Source e blogueiro nas horas vagas. Autor e mantenedor do portal Terminal de Informação.

Deixe uma resposta

Terminal de Informação