Rendimiento de consultas SQL
En este caso en particular, no notará una gran diferencia porque 30 000 filas no son demasiado difíciles de procesar para la base de datos. Sin embargo, si estuvieras hablando de cientos de millones de filas o más, verías una mejora notable al agregarlas antes de unirte. Al hacer esto, asegúrese de que lo que está haciendo es lógicamente consistente: debe preocuparse por la precisión de su trabajo antes de preocuparse por la velocidad de carrera.
13 CONSEJOS DE RENDIMIENTO DE CONSULTAS
Recuerde poner un prefijo a los nombres de objetos (p. ej. tabla, procedimiento almacenado, vista) con su propietario / nombre de esquema.
Motivo: Si no se proporciona el nombre de propietario/esquema, el motor de SQL Server intenta encontrarlo en todos los esquemas hasta que el objeto lo encuentre. El motor de SQL Server no buscará la tabla fuera de su propietario/esquema si se proporciona el nombre propietario/esquema.
El operador *
No utilice el operador * en sus instrucciones SELECT. En su lugar, use nombres de columna.
Motivo: SQL Server busca todos los nombres de columna y reemplaza el * por todos los nombres de columna de las tablas de la instrucción SQL SELECT. Proporcionar nombres de columna evita esta búsqueda y reemplazo y mejora el rendimiento.
Columnas nullables
Evite usar NO IN al comparar con columnas nullables. Use NO EXISTE en su lugar.
Motivo: Cuando se usa NOT IN en la consulta (incluso si la consulta no devuelve filas con los valores nulos), SQL Server comprobará cada resultado para ver si es nulo o no. Usar NO EXISTE no hará la comparación con nulos. Además, NOT EXISTS devuelve solo dos estados (verdadero o falso), mientras que NOT IN puede devolver hasta tres estados (verdadero, falso, NULO) y podría no darle el resultado que esperaba.
Variables de tabla y uniones
Evite usar variables de tabla en uniones. Utilice tablas temporales, CTE (Expresiones de tabla Comunes) o tablas derivadas en uniones en su lugar.
Razón: Aunque las variables de tabla son muy rápidas y eficientes en muchas situaciones, el motor de SQL Server las ve como una sola fila. Debido a esta razón, SQL producirá un plan de ejecución que funcionará de manera horrible cuando se use en uniones.
Nombres de procedimientos almacenados
No comience el nombre de su procedimiento almacenado con sp_.
Motivo: Cuando el procedimiento almacenado se llama sp_ o SP_, SQL Server siempre comprueba la base de datos del sistema / maestro, incluso si se proporciona el nombre propietario / esquema. Proporcionar un nombre sin SP_ a un procedimiento almacenado evita esta comprobación innecesaria en la base de datos del sistema/maestro en SQL Server.
Use ESTABLECER NOCOUNT EN
Use ESTABLECER NOCOUNT EN operaciones DML.
Motivo: Al realizar operaciones DML (p. ej. INSERTAR, ELIMINAR, SELECCIONAR y ACTUALIZAR), SQL Server siempre devuelve el número de filas afectadas. En consultas complejas con muchas uniones, esto se convierte en un gran problema de rendimiento. El uso de ESTABLECER NOCOUNT ON mejorará el rendimiento porque no hará un seguimiento del número de filas afectadas.
Evite usar GRUPO POR, ORDEN POR y DISTINTO
Evite usar GRUPO POR, ORDEN POR y DISTINTO siempre que sea posible.
Motivo: Al usar AGRUPAR POR, ORDENAR POR o DISTINTO, el motor de SQL Server crea una tabla de trabajo y coloca los datos en la tabla de trabajo. Después de eso, organiza estos datos en la tabla de trabajo según lo solicitado por la consulta, y luego devuelve el resultado final.
Comprobar índices
Debe haber índices en todos los campos utilizados en las partes WHERE y JOIN de la instrucción SQL.
Motivo: Cuando los campos no están indexados, SQL Server normalmente realiza un análisis completo de la tabla y esto puede reducir el rendimiento. A menos que la tabla sea muy pequeña, un análisis de tabla tiende a producir el peor rendimiento de todos los tipos de lecturas de base de datos.
Use el mismo tipo de datos al UNIR y las cláusulas WHERE
Esto es más fácil de decir que de hacer dependiendo de sus permisos para realizar cambios en el esquema.
Motivo: Al unir o comparar dos campos con tipos de datos diferentes, SQL debe realizar una conversión sobre la marcha del campo antes de poder hacer una comparación, incluso si los campos están indexados. Si los tipos de datos no coincidentes son inevitables, intente convertir el tipo de datos más grande al tipo de datos más pequeño siempre que sea posible.
Evite el uso de Campos calculados en las cláusulas JOIN y WHERE
Esto se puede hacer creando un campo con los valores calculados utilizados en la combinación en la tabla. Véase más adelante.