Sidebar

SQL Server realiza una serie de tareas antes de ejecutar un query sobre el manejador de base de datos. El performance que tenga este en traernos la información, depende de varios factores. Conoce algunos de ellos y como son procesados por SQL Server para que tus aplicaciones no sufran de un mal performance.  
Como SQL Server procesa los queries
SQL Server realiza una serie de pasos para ejecutar un query por primera vez, después de que se inicia el servidor de base de datos. Los pasos son los siguientes:

Paso
Descripción
Parsing
Se verifica la sintaxis del query
Resolving
Se verifican los nombres de los objetos usados en el query y se verifica que se tengan los permisos necesarios
Optimizing
Se verifica si existen índices y cual de ellos puede usar para optimizar la consulta y como puede unir las tablas (join) de ser necesario.
Compiling
SQL Server convierte el query en lenguaje ejecutable e incluye identificadores para las tablas e índices que debe utilizar para extraer los datos.
Executing
SQL Server envía la sentencia compilada para su ejecución

Cuando el optimizador de consultas (una parte del motor de base de datos) optimiza un query, analiza todas las posibles soluciones que puede utilizar para extraer la información, para posteriormente seleccionar la que genera un menor costo. Menor costo significa que la forma de extraer la información es la que genera menos carga al CPU. Por ejemplo el query processor puede seleccionar entre ejecutar un table scan o utilizar un índice.
Después de que SQL Server genera todas las posibles soluciones para ejecutar un query, guarda este paso en memoria como un plan de ejecución. Este proceso es llamado caching, y el segmento de memoria donde SQL Server guarda el plan de ejecución es llamado procedure cache.
SQL Server automáticamente guarda todos los planes de ejecución en el procedure cache. Después el tratara de reutilizarlos cuando tratemos de ejecutar el mismo query o alguno similar. Por ejemplo revisemos los siguientes dos escenarios. Cuando ejecutamos un query en el Analizador de Consultas, este tipo de queries son llamados ad hoc queries. Si ejecutamos dos ad hoc queries idénticos SQL Server reutilizara el planes de ejecución.
SELECT * FROM movie WHERE rentalprice = 2.99
SELECT * FROM movie WHERE rental_price = $2.99
SELECT * FROM movie WHERE rating = 2.99
En este ejemplo SQL Server reutilizara el plan de ejecución del primer query cuando ejecute el tercer query. Esto es porque estos dos queries son idénticos a diferencia del segundo que su condición de búsqueda es diferente.
Si dos queries son similares pero no exactamente identicos, SQL Server tratara de auto parametrizarlos. En este caso SQL Server tratara de convertir la constante (el valor especificado en la sentencia WHERE) en un parámetro. Por ejemplo, si ejecutamos los dos siguientes queries SQL Server tratara de auto parametrizarlos con un plan de ejecución en el cache y reutilizarlo para el segundo query.
SELECT title, rental_price FROM movie WHERE rating = 'G'
SELECT title, rental_price FROM movie WHERE rating = 'PG'
Optimizando el performance de los queries
Trate de evitar el uso de búsquedas negativas. Por ejemplo el use condiciones de búsqueda como NOT LIKE, NOT BETWEEN y NOT NULL afectan el performance de SQL Server ya que deben de evaluar todos los registros de la tabla.
Se va observar un mejor performance si se utilizan condiciones de búsqueda exactos.
Se puede observar un decremento del performance cuando se use la clausula ORDER BY porque SQL Server debe filtrar y ordenar los datos antes de poder desplegar los resultados.
Trate de no utilizar la condición de búsqueda LIKE si se puede usar un query más exacto. Le toma mas tiempo a SQL Server procesar los queries que contienen la palabra LIKE comparado con queries más exactos como WHERE titulo = 'Hoteles'

Search

Tips BD