¡Hola, chicos!
¡Buenas noches!

Hoy me encontré con un problema crítico de rendimiento en un entorno de producción, donde cierta consulta (que se puede ejecutar varias veces por segundo) presentaba un problema de lentitud (tardaba entre 21 y 30 segundos por ejecución) que ya era viejo y conocido, pero hoy era el día para resolverlo de una vez por todas.

Para muchos DBA (incluyéndome a mí) y entusiastas del modelado de bases de datos, este tipo de problema nunca debería ocurrir, pero desafortunadamente en la práctica esto no es lo que sucede. Analizando la consulta, que por cierto era bastante grande, con varios CASOS, LEFT JOIN’S, OR’s, uso de funciones, etc. pude ver que había muchos casos de conversión implícita y al analizar el plan de ejecución real, el motivo de la lentitud era muy claro:

SQL Server - JOIN Predicate Columns Different DataTypes 2
SQL Server - ÚNETE a columnas de predicado diferentes tipos de datos 2

Analizando las lecturas de disco podemos observar que las lecturas en una tabla específica son muy altas, sobre todo si tomamos en cuenta que la consulta utiliza en la cláusula WHERE un término de igualdad en la tabla principal de la consulta, informando un código que es la clave primaria y está en el índice agrupado, es decir, debe ser una consulta sumamente rápida y optimizada, procesando pocos registros.

SQL Server - JOIN Predicate Columns Different DataTypes 3
SQL Server - ÚNETE a columnas de predicado diferentes tipos de datos 3

Observe que hay una advertencia en la selección. Y colocando el ratón sobre él podremos visualizar esta información:

SQL Server - Differente Datatypes Performance Problems 2
SQL Server: problemas de rendimiento de diferentes tipos de datos 2

Bueno, tenemos el problema de conversión implícita. Esto ocurre cuando se comparan dos columnas de diferentes tipos de datos y luego la base de datos necesita convertirlas manualmente durante la consulta.

Analizando las JOINS de la consulta, pude ver que las columnas involucradas en la comparación eran de diferentes tipos. Esto significa que todos los registros involucrados en JOIN deben convertirse al mismo tipo y luego verificar si deben estar restringidos por las cláusulas JOIN o no. Si el volumen de registros es muy alto, esto puede aumentar considerablemente el tiempo de procesamiento y las lecturas del disco (como se demuestra en el ejemplo)

Un simple comando ALTER TABLE en la columna que estaba realizando la UNIÓN de la tabla que tenía muchas lecturas para coincidir con los tipos de datos resolvió el problema:

SQL Server - JOIN Predicate Columns Different DataTypes 1
SQL Server: ÚNETE a columnas de predicado diferentes tipos de datos 1

SQL Server - JOIN Predicate Columns Different DataTypes 4
SQL Server: ÚNETE a columnas de predicado con diferentes tipos de datos 4

Otra solución sería crear una tabla intermedia que contenga parte de la consulta y convertir la columna al tipo correcto. Con esta tabla intermedia el JOIN se realizaría con el resto de la consulta, y ahora, con el mismo tipo de datos, ya no habría el problema de la conversión implícita y la consulta se ejecutaría de forma más optimizada.

¡Eso es todo, amigos!
¡Un abrazo y nos vemos en el próximo post!