Tipos de datos Unicode e impacto en la performance


Los tipos de datos UNICODE que podemos usar con el NCHAR() o NVARCHAR() en muchos casos son útiles si deseamos guardar caracteres de este tipo. Ahora bien, cual es el problema si diseñamos una base con este tipo de caracteres y no los tenemos? en principio uno podría decir que nada ya que si no están el tipo de dato guardara los caracteres normales, pero….  para poder guardar los Unicode necesita el SQL un byte mas por carácter por ello el máximo de un varchar o char común es de 8000 y el de un NChar o Nvarchar es de 4000.

Lo que haremos en este post es observar que sucede con la performance si usamos uno u otro tipo de dato

Primer paso:

Lo primero que haremos es crear dos tablas iguales solo que una esta definida como Unicode y la otra no. Luego a cada una de ellas le insertaremos 1Millon de registros iguales

Segundo paso:

Observaremos el espacio ocupado por cada una de estas tablas usando SP_SPACEUSED

 

image

Como podemos observar en los resultados la tabla con Unicode pesa casi el doble que la otra tabla.

Prueba de performance:

Ahora lo que vamos a hacer es un SELECT de ambas tablas las cuales harán el mismo plan de ejecución (Query Plan) pero al ser mas pesado uno que el otro lo veremos representado en los costos de cada QP

image

 

Conclusiones:

Como siempre decimos hay que ser muy cuidadoso con los tipos de datos a elegir porque el peso juega en la performance, siempre hay que recordar que el costo de un plan de ejecución toma en cuenta el costo de CPU y el de I/O.

Con los datos Unicode recomiendo al igual que los otros tipos de datos analizarlos con cuidado y solo aplicarlos donde se considere será necesario.