Este documento proporciona sugerencias para mejorar el rendimiento de las consultas SQL. Recomienda 1) evitar el uso excesivo de cursores y en su lugar utilizar instrucciones como GROUP BY o CASE, 2) aprovechar la parametrización de consultas para permitir la reutilización de planes de ejecución almacenados en caché, y 3) reescribir consultas complejas como aquellas que devuelven grandes conjuntos de resultados o usan cláusulas WHERE no únicas.

1. INSTITUTO TECNOLOGICO DE OCOTLAN.
ING. SISTEMAS COMPUTACIONALES
BASE DE DATOS
SUGERENCIAS PARA LAS CONSULTAS EN SQL
UNIDAD 2.

2. SUGERENCIAS PARA CONSULTAS EN SQL.
1. Uso de cursores
Si la consulta utiliza cursores, determina antes si es posible escribirla con un tipo de cursor
más eficaz (uno de avance rápido) o con una única consulta. Las consultas
únicas mejoran las operaciones de cursor.
Dado que un conjunto de instrucciones de cursor suele constituir una operación de bucle
externo, en la que cada fila se procesa una vez con una instrucción interna, puedes
contemplar la posibilidad de usar en su lugar una instrucción GROUP BY o CASE. Quizá
incluso una subconsulta.
2. Uso de alias
Utilizar varios alias para una sola tabla en la misma consulta para simular la intersección de
índices ya no es necesario. SQL Server tiene en cuenta automáticamente la intersección
de índices y puede utilizar varios en la misma tabla.
3. Uso de la parametrización
Utiliza la parametrización de consultas para permitir la reutilización de los planes de
ejecución de consulta almacenados en la memoria caché. Si un conjunto de consultas
comparte el mismo hash de consulta y hash de plan de consulta podrías mejorar el
rendimiento creando una consulta parametrizada.
Además, si llamas a una consulta con parámetros, en lugar de a varias consultas con
valores literales, podrás reutilizar el plan de ejecución de consulta almacenado en la
memoria caché.
4. Uso de Exists
Cuando queramos hacer una sub-consulta en una base de datos utilizando la sentencia
NOT IN, analicemos si podemos cambiar nuestro quieres con el uso de la sentencia Exists
que es mucho más eficiente que la anterior. O en todo caso, utilizar IN en vez de NOT IN,
ya que esto hace un escaneo completo en la tabla descartando opciones a omitir.
5. Uso de Distinct
Utilizar distinct para excluir datos duplicados es muy usado por los programadores para
evitar errores de diseño de base de datos y así esconder algunos duplicidad de
información, pero esto es un grave error. Es una de las sentencias que más necesita hacer
I/O en el disco y forzar bastante el procesador. Por tal motivo, si no es necesario evitemos
utilizarla.
6. Uso de Tops
Cuando se quiere traer un grupo de registros es mejor utilizar la sentencia Top y no
Rowcount, ya que esta última presenta inconvenientes con listas no ordenadas. En
cambio, si la lista es ordenada es más eficiente que la sentencia Top.

3. 7. Uso de*.
Cuando se realizan consultas que van a devolver muchos campos es mejor definir todos
los campos que queremos devolver en nuestro quieres, ya que el uso de * o Al impide el
uso de índices de forma eficiente.
8. Verificar si existe un registro
Muchos programadores utilizan el count (*) para ver si un registro existe en la base de
datos, pero una forma más eficiente de hacerlo es con Exists. Cuando éste encuentra un
registro detiene la búsqueda del mismo.
9. Uso de ORDER BY
Usar ORDER BY en las QUERIES que se lancen sólo si es absolutamente indispensable. Es
decir, que si es posible realizar la ordenación en el lado del cliente siempre será mejor que
realizarla desde el lado del servidor SQL Server.
En caso de que sea absolutamente necesario realizar la ordenación en el lado del
servidor SQL Server deberemos atender a las siguientes recomendaciones:
1. Mantener el número de filas a ordenar al mínimo
2. Mantener el número de columnas a ordenar al mínimo
3. Mantener el ancho (tamaño físico) de las columnas a ordenar al mínimo
4. Ordenar columnas con datos numéricos (NO tipos de datos carácter)
10. No usar el comando GROUP BY
No usarlo al menos sin una función de agregación. La cláusula GROUP BY puede usarse
con o sin una función de agregación. Pero si queremos obtener un mejor rendimiento, no
usaremos la cláusula GROUP BY sin una función de agregación. Esto es porque produce el
mismo resultado usar DISTINCT y es más rápido.
Para acelerar el uso de la cláusula GROUP BY debemos seguir las siguientes
recomendaciones:
1. Mantener al mínimo el número de filas a devolver por la Query.
2. Mantener al mínimo el número de agrupaciones
3. No agrupar columnas redundantes
4. Cambiar un JOIN por una SUBQUERY cuando hay uno en la misma SELECT que tiene un
GROUP BY.
OTRAS RECOMENDACIONES SON.
Algunas consultas consumen más recursos que otras. Por ejemplo, las consultas que
devuelven grandes conjuntos de resultados y las que contienen cláusulas WHERE que no
son únicas siempre consumen muchos recursos. Ningún grado de inteligencia del
optimizador de consultas puede eliminar el costo de recursos de estas construcciones en

4. comparación con una consulta menos compleja. SQL Server utiliza un plan de acceso
óptimo, pero la optimización de consultas está limitada por lo que es posible.
Sin embargo, para mejorar el rendimiento de las consultas, puede:
 Agregar más memoria. Esta solución es especialmente útil si el servidor ejecuta
muchas consultas complejas y varias consultas se ejecutan lentamente.
 Utilizar más de un procesador. Varios procesadores permiten que el Motor de base
de datos use consultas en paralelo. Para obtener más información, vea Procesar
una consulta en paralelo.
 Vuelva a escribir la consulta. Considere lo siguiente:
o Si la consulta utiliza cursores, determine si se puede escribir la consulta de
cursor con un tipo de cursor más eficaz (como un curso de sólo avance
rápido) o con una única consulta. Las consultas únicas normalmente
mejoran las operaciones de cursor. Debido a que un conjunto de
instrucciones de cursor suele constituir una operación de bucle externo, en
la que cada fila del bucle externo se procesa una vez con una instrucción
interna, considere la posibilidad de utilizar en su lugar una instrucción
GROUP BY o CASE, o una subconsulta. Para obtener más información,
vea Tipos de cursores (motor de base de datos) y Aspectos básicos de las
consultas.
o Si una aplicación utiliza un bucle, considere la posibilidad de colocar el
bucle en la consulta. A menudo, una aplicación contendrá un bucle que,
a su vez, contendrá una consulta con parámetros que se ejecuta muchas
veces y será necesario realizar un viaje de ida y vuelta en la red entre el
equipo que ejecuta la aplicación y SQL Server. En su lugar, cree una sola
consulta más compleja con una tabla temporal. Sólo necesita un viaje de
ida y vuelta en la red, y el optimizador de consultas puede optimizar mejor
la consulta única. Para obtener más información, vea Procedimientos de
Transact-SQL y Variables de Transact-SQL.
o No utilice varios alias para una sola tabla en la misma consulta para simular
la intersección de índices. Ya no es necesario debido a que SQL Server
tiene en cuenta automáticamente la intersección de índices y puede
utilizar varios índices en la misma tabla de la misma consulta. Observe el
ejemplo de consulta:
o SELECT * FROM limiten
o WHERE partkey BETWEEN 17000 AND 17100 AND
o shipdate BETWEEN '1/1/1994' AND '1/31/1994'
SQL Server puede utilizar índices sobre las columnas partkey y shipdate, y
después realizar una coincidencia hash entre los dos subconjuntos para
obtener la intersección de ííndices.
o Utilice la parametrización de consultas para permitir la reutilización de los
planes de ejecución de consulta almacenados en la memoria caché. Si un
conjunto de consultas tiene el mismo hash de consulta y hash de plan de
consulta, podría mejorar el rendimiento creando una consulta
parametrizada. Llamar a una consulta con parámetros en lugar de a varias
consultas con valores literales permite reutilizar el plan de ejecución de
consulta almacenado en la memoria caché. Para obtener más
información, vea Buscar y optimizar consultas similares utilizando hash del

5. plan de consulta y de consulta y Almacenar en caché y volver a utilizar un
plan de ejecución.
Si no puede modificar la aplicación, puede utilizar las guías de plan de la
plantilla con parametrización forzada para lograr un resultado similar. Para
obtener más información, vea Especificar el comportamiento de
parametrización de consultas por medio de guías de plan.
o Utilice sugerencias de consultas sólo si es necesario. Las consultas que
utilizan sugerencias ejecutadas en versiones anteriores de SQL Server deben
probarse sin las sugerencias especificadas. Las sugerencias pueden impedir
que el optimizador de consultas seleccione un plan de ejecución mejor.
Para obtener más información, vea SELECT (Transact-SQL).
 Utilice query_plan_hash para capturar, almacenar y comparar los planes de
ejecución de consulta de las consultas a lo largo del tiempo. Por ejemplo, después
de cambiar la configuración del sistema, puede comparar los valores hash del
plan de consulta de las consultas esenciales con sus valores hash de plan de
consulta originales. Las diferencias en los valores pueden indicarle si el cambio de
la configuración del sistema produjo planes de ejecución de consulta actualizados
para las consultas importantes. También podría decidir detener la ejecución de
una consulta de larga duración si su hash de plan de consulta en
sys.dm_exec_requests difiere de su hash de plan de consulta de línea base, que se
sabe que tiene un buen rendimiento. Para obtener más información, vea Buscar y
optimizar consultas similares utilizando hash del plan de consulta y de consulta.
 Utilice la opción de configuración query governor (regulador de consultas). Puede
utilizar la opción de configuración query governor para impedir que se consuman
recursos del sistema al ejecutar consultas de larga duración. De forma
predeterminada, la opción se establece para permitir que se ejecuten todas las
consultas, sin importar su duración. Sin embargo, se puede establecer el regulador
de consultas en el número máximo de segundos que está permitido ejecutar todas
las consultas de todas las conexiones o sólo las consultas de una conexión
específica. Debido a que el regulador de consultas se basa en el costo estimado
de las consultas en lugar de en el tiempo real transcurrido, no tiene sobrecarga de
tiempo de ejecución. También detiene las consultas de larga duración antes de
que comiencen, en lugar de ejecutarlas hasta que se alcance el límite definido
previamente. Para obtener más información, vea query governor cost limit,
opción y SET QUERY_GOVERNOR_COST_LIMIT (Transact-SQL).
 Optimice la reutilización de los planes de consultas de la caché del plan. Motor de
base de datos almacena en memoria caché los planes de consultas para una
posible reutilización. Si un plan de consulta no se pone en la caché, nunca podrá
reutilizarse. En su lugar, los planes de consulta que no están en la caché deben
compilarse cada vez que se ejecutan, lo que produce un bajo rendimiento. Las
siguientes opciones de la instrucción Transact-SQL SET impiden que los planes de
consulta que están en la caché se reutilicen. Un lote de Transact-SQL que
contenga estas opciones SET activadas no puede compartir sus planes de consulta
con el mismo lote que se compiló cuando estas opciones SET estaban
desactivadas:
SET ANSI_NULL_DFLT_OFF SET ANSI_NULL_DFLT_ON

6. SET ANSI_NULLS SET ANSI_PADDING
SET ANSI_WARNINGS SET ARITHABORT
SET CONCAT_NULL_YIELDS_NULL SET DATEFIRST
SET DATEFORMAT SET FORCEPLAN
SET LANGUAGE SET NO_BROWSETABLE
SET NUMERIC_ROUNDABORT SET QUOTED_IDENTIFIER
SET TEXTSIZE