Conversão Implícita no SQL Server — Performance Tuning

Alan Nunes
Comunidade XP
3 min readJun 20, 2022

--

Antes de introduzir o assunto, gostaria de destacar que todo o artigo foi motivado por um acontecimento real. Aproveite a leitura!

Introdução

Ao comparar valores com tipos de dados diferentes, o SQL Server faz automaticamente uma conversão implícita antes de realizar essa comparação. Por exemplo, imagine um SELECT que recebe um filtro do tipo NVARCHAR em uma coluna que é VARCHAR:

Exemplo de conversão implícita.

Nesse caso temos uma conversão implícita de NVARCHAR para VARCHAR que fará nosso SELECT funcionar, porém isso trás sérios riscos de performance e vamos discutir sobre eles.

Por que Evitar Conversões Implícitas

A conversão implícita além de forçar uma carga de trabalho a mais, ela também pode confundir o MSSQL na geração de um bom plano de execução, mesmo que você tenha um bom índice. A queda de performance pode passar despercebida em tabelas pequenas, mas quando trabalhamos com tabelas grandes, o gargalo fica nítido.

Para exemplificar a diferença quando há conversão implícita, iremos usar a seguinte estrutura:

Estrutura SQL para o exemplo

Exemplo de Plano de Execução Com Conversão Implícita

Neste exemplo é possível notar através do plano de execução que há uma conversão implícita e que o plano gerado faz um Index Scan. Esse plano poderia ser melhor.

Exemplo SQL com conversão implícita
Plano de execução ruim devido conversão implícita

Exemplo de Plano de Execução Sem Conversão Implícita

Agora neste exemplo nota-se que o plano gerado ficou bom, usando um Index Seek, que fará nossa query ter uma boa performance.

Exemplo SQL sem conversão implícita
Plano de execução bom

Exemplo de Um Case Real

Esse case será narrado contando a história de um desenvolvedor apelidado por um nome fictício: João.

João precisava desenvolver uma feature em uma aplicação C# que fizesse delete em uma base de dados SQL Server, então escreveu a query e rodou no MSSQL Management Studio:

Query escrita por João

A performance estava ótima, executando em poucos milisegundos.

Então João foi para o próximo passo, implementou a query na aplicação usando Dapper:

Utilizando Dapper para Fazer o Delete

Porém ao executar a aplicação, a query rodava por minutos e sempre tomava timeout. Então surge o questionamento:

Por que no C# a performance está ruim mas no Management Studio está boa?

Após dias procurando a resposta, João descobre que o problema se tratava de conversão implícita e o responsável por isso, era o Dapper, que convertia o parâmetro CodigoAtivo de String para NVARCHAR.

Para resolver isso, João precisou tipar explicitamente o tipo de dado enviado para o Dapper:

Utilizando Dapper sem conversão implícita

Depois disso, a query voltou a executar em milisegundos.

Conclusão

Ás vezes a conversão implícita pode passar despercebida. E esse artigo foi escrito especialmente para isso. Agora você poderá usar esse conhecimento para não passar horas procurando um problema tão minucioso como este.

Bônus

Conversão implícita não é algo estritamente ligado ao MSSQL, ela pode acontecer no Oracle também, por exemplo.

A conversão implícita não aparece em todos os casos e para saber quando ela pode acontecer, veja a tabela abaixo disponibilizada pela documentação da Microsoft:

Fonte: https://docs.microsoft.com/en-us/sql/t-sql/data-types/data-type-conversion-database-engine?view=sql-server-ver16

--

--