Aplicar correcta indexación en las columnas de las tablas en la base de datos
- asegurarse de que cada tabla en su base de datos tiene una clave principal.
Esto asegurará que cada tabla tenga un índice agrupado creado (y por lo tanto, las páginas correspondientes de la tabla se clasifican físicamente en el disco de acuerdo con el campo de clave principal). Entonces, cualquier operación de recuperación de datos de la tabla usando la clave primaria, o cualquier operación de clasificación en el campo de clave primaria o cualquier rango de valores de clave primaria especificados en la cláusula where recuperará datos de la tabla muy rápido.
crear índices no agrupados en columnas, que son
utiliza con frecuencia en los criterios de búsqueda.
Se utiliza para unir otras tablas.
Se utiliza como campo de clave externa.
De alta selectividad (columna que devuelve un bajo porcentaje (0-5%) de filas de un número total de filas en un valor particular).
Se utiliza en la cláusula ORDER BY.
No utilice "SELECT *" en una consulta SQL
columnas innecesarias pueden obtener inverosímil que se sumará a expensas del tiempo de recuperación de datos. El motor de base de datos no puede utilizar el beneficio de "Índice cubierto" y, por lo tanto, la consulta se realiza lentamente.
Ejemplo:
SELECT Cash, Age, Amount FROM Investments;
En lugar de:
SELECT * FROM Investments;
Trate de evitar tener Cláusula en las sentencias SELECT
HAVING se utiliza para filtrar las filas después de todas las filas son seleccionado y se usa como un filtro. Intenta no usar la cláusula HAVING para ningún otro propósito.
Ejemplo:
SELECT Name, count (Name) FROM Investments WHERE Name!= ‘Test’ AND Name!= ‘Value’ GROUP BY Name;
En lugar de:
SELECT Name, count (Name) FROM Investments GROUP BY Name HAVING Name!= ‘Test’ AND Name!= ‘Value’ ;
tratar de minimizar el número de bloques de consulta sub dentro de una consulta
A veces puede tener más de una consulta sub en nuestra consulta principal. Deberíamos intentar minimizar el número de bloque de sub consulta en nuestra consulta.
Ejemplo:
SELECT Amount FROM Investments WHERE (Cash, Fixed) = (SELECT MAX (Cash), MAX (Fixed) FROM Retirements) AND Goal = 1;
En lugar de:
SELECT Amount FROM Investments WHERE Cash = (SELECT MAX (Cash) FROM Retirements) AND Fixed = (SELECT MAX (Fixed) FROM Retirements) AND Goal = 1;
Evita columnas innecesarias en la lista SELECT y mesas innecesarios en condiciones de combinación
Selección de columnas innecesarias en una consulta de selección agrega sobrecarga a la consulta real, especialmente si las columnas innecesarias son de tipos LOB. La inclusión de tablas innecesarias en condiciones de combinación fuerza al motor de la base de datos a recuperar y recuperar datos innecesarios y aumenta el tiempo de ejecución de la consulta.
No utilice el agregado COUNT() en una subconsulta que hacer una comprobación de la existencia
Cuando se utiliza COUNT(), SQL Server no sabe que usted está haciendo una comprobación de la existencia. Cuenta todos los valores coincidentes, ya sea haciendo un escaneo de tabla o escaneando el índice no agrupado más pequeño. Cuando utiliza EXISTS, SQL Server sabe que está haciendo una comprobación de existencia. Cuando encuentra el primer valor coincidente, devuelve TRUE y deja de buscar.
Trate de evitar de unión entre dos tipos de columnas
Cuando unión entre dos columnas de diferentes tipos de datos, una de las columnas deben ser convertidos con el tipo de la otra.La columna cuyo tipo es más bajo es la que se convierte. Si une tablas con tipos incompatibles, una de ellas puede usar un índice, pero el optimizador de consultas no puede elegir un índice en la columna que convierte.
No trate de usar COUNT (*) para obtener el número de registros en una tabla
Para obtener el número total de filas en una tabla, que suelen utilizar la siguiente instrucción SELECT:
SELECT COUNT(*) FROM [dbo].[PercentageForGoal]
Esta consulta realizará un escaneo completo de la tabla para obtener el recuento de filas. La siguiente consulta no requerirá un escaneo de tabla completo. (Tenga en cuenta que esto no se podría dar el 100% siempre resultados perfectos, pero esto es útil sólo si no es necesario un recuento perfecto.)
SELECT rows FROM sysindexes
WHERE id = OBJECT_ID('[dbo].[PercentageForGoal]') AND indid< 2
intenta utilizar operadores como Existe, y se une apropiadamente en su consulta
- Normalmente, IN tiene el rendimiento más lento.
- IN es eficiente, solo cuando la mayoría de los criterios de filtro para la selección se colocan en la subconsulta de una instrucción SQL.
- EXISTS es eficiente cuando la mayoría de los criterios de filtro para la selección se encuentra en la consulta principal de una instrucción de SQL.
Trate de evitar el SQL dinámico
A menos que realmente se requiere, trate de evitar el uso de SQL dinámico porque: SQL dinámico es difícil de depurar y solucionar problemas. Si el usuario proporciona la entrada al SQL dinámico, existe la posibilidad de ataques de inyección SQL.
Trate de evitar el uso de tablas temporales
A menos que realmente necesario, tratar de evitar el uso de tablas temporales. Más bien use variables de tabla. En el 99% de los casos, las variables de tabla residen en la memoria, por lo tanto, es mucho más rápido. Las tablas temporales residen en la base de datos TempDb. Entonces, operar en tablas temporales requiere comunicación entre bases de datos y, por lo tanto, será más lento.
lugar de como la búsqueda, usar la búsqueda de texto completo para la búsqueda de datos textuales
búsquedas de texto completo siempre superan COMO búsquedas. Las búsquedas de texto completo le permitirán implementar criterios de búsqueda complejos que no pueden implementarse utilizando una búsqueda LIKE, como buscar en una sola palabra o frase (y opcionalmente, clasificar el conjunto de resultados), buscar en una palabra o frase cercana a otra palabra o frase, o buscar en formas sinónimas de una palabra específica. La implementación de la búsqueda de texto completo es más fácil de implementar que la búsqueda LIKE (especialmente en el caso de los requisitos de búsqueda compleja).
Intente utilizar UNION para implementar un "OR"
trate de no usar "O" en una consulta. En su lugar, use "UNION" para combinar el conjunto de resultados de dos consultas distinguidas. Esto mejorará el rendimiento de la consulta. Mejor uso UNIÓN TODO si no se requiere un resultado distinguido. UNION ALL es más rápido que UNION ya que no tiene que ordenar el conjunto de resultados para descubrir los valores distinguidos.
implementar una estrategia de carga diferida para grandes objetos
Tienda columnas de objetos grandes (como VARCHAR (MAX), imagen, texto, etc.) en una tabla diferente a la tabla principal, y poner una referencia a la objeto grande en la mesa principal. Recupere todos los datos de la tabla principal en una consulta, y si es necesario cargar un objeto grande, obtenga los datos de objetos grandes de la tabla de objetos grandes solo cuando sea necesario.
implementar las siguientes buenas prácticas en las funciones definidas por el usuario
No llame a funciones repetidamente dentro de sus procedimientos almacenados, triggers, funciones y lotes. Por ejemplo, puede necesitar la longitud de una variable de cadena en muchos lugares de su procedimiento, pero no llame a la función LEN cuando sea necesario; en su lugar, llame a la función LEN una vez, y almacene el resultado en una variable para su uso posterior.
implementar las siguientes buenas prácticas en disparadores
- tratar de evitar el uso de los factores desencadenantes. Disparar un disparador y ejecutar el evento desencadenante es un proceso costoso.
- Nunca utilice desencadenantes que puedan implementarse utilizando restricciones.
- No utilice el mismo activador para diferentes eventos de activación (Insertar, Actualizar y Eliminar).
- No utilice código transaccional dentro de un desencadenador. El desencadenador siempre se ejecuta dentro del alcance transaccional del código que desencadena el activador.
Estoy de acuerdo con esto: los sistemas de bases de datos involucran trozos de metal que van y vuelven. Estos trozos de metal no se están volviendo exponencialmente más rápidos en la forma en que son los IC y el error en la consulta puede hacer órdenes de diferencia de magnitud en el rendimiento. – ConcernedOfTunbridgeWells
De hecho, reemplacé los cursores con un código basado en conjuntos que tomaba el rendimiento en minutos a milisegundos y algunas veces de horas a segundos. No es necesario escribir este tipo de código para comenzar. – HLGEM
La optimización prematura se trata de evitar optimizar algo cuando no se tienen medidas sobre cuánto tiempo/esfuerzo se guardará. Evitar el uso de cursores no es una optimización prematura, ya que hay una mejora muy convincente y bien documentada en el rendimiento para evitarlos. – Nat