Hace poco dejé en el Blog un breve artículo sobre
7 consejos para acelerar tus consultas SQL. A raíz de él vamos a ver más en detalle, de forma más práctica, como llevar dichos consejos a tu base de datos y que ésta corra como nunca. Recuerda que es más importante optimizar tus queries, establecer correctamente los índices, etc que poner un hardware más potente a tu servidor.
* Sentencia UNION. Si para el resultado de la consulta no nos preocupa recuperar tuplas duplicadas usaremos mejor UNION ALL, ya que no hará internamente por defecto el select distinct tras combinar los registros de ambas tablas.
* Evitar SELECT * ..... Devolver siempre únicamente los campos que necesitamos: select campo1,campo2....
* Usar SELECT TOP n campo1,campo2 en consultas que sabemos devolverán un número alto de registros al usuario y éste no gestionará todos ellos. ¡Evita sobreesfuerzos al motor de tu base de datos!.
* Evitar NOT IN , usando en su lugar preferentemente alguna de estas sentencias (en orden de mejor rendimiento a menor): EXISTS ó IN ó LEFT OUTER JOIN con chequeo de condición NULL.
* Forzar índices. Ej: SELECT campo1,campo2 FROM Tabla1 (INDEX = IX_ProcessID) WHERE campo3 = 1 AND processid IN (8,32,45)
* Concatenación de ANDs "inteligente". Si tenemos un WHERE cond1 AND cond2 AND cond3 significa que cond1 debe ser la menos probable a suceder para que si es así NO SE EVALÚEN las otras condiciones. Si todas las condiciones tienen "igual peso" las pondremos en orden de complejidad: las más simples primero. En las condiciones que se establezcan en la cláusula WHERE al menos una de ellas debería basarse en una columna lo más selectiva posible y que sea parte de un INDICE. Si al menos uno de los criterios de búsqueda en la cláusula WHERE no es altamente selectivo, consideraremos añadir INDICES para todas las columnas referenciadas en la cláusula WHERE.
* SELECT INTO. Este tipo de sentencia suele producir bloqueos por lo que hay que usarla en momentos de menor actividad.
* GROUP BY. Preferentemente usarlo con funciones de agregación, es decir, es mejor un select distinct(campo1) from tabla where campo2>10 que usar select campo1 from tabla where campo2>10 group by campo1.
* Para comprobar la existencia de registros en una tabla ¡NO USAR count(*)!. Es mucho más eficiente IF EXISTS. La razón es simple: el count(*) procesa TODAS las filas mientras que EXISTS para la ejecución cuando encuentra algún registro que cumpla la condición.
* En SELECT masivos mejor usar la instrucción (nolock) para no bloquear los registros obtenidos.Y en general para evitar interbloqueos recordad siempre las reglas de cliente-servidor: conectar, ejecutar, recibir y desconectar.
