usar - rendimiento sql explicado pdf

¿Cuáles son tus optimizaciones sql más comunes? (17)

¿Cuál es la optimización SQL más común que usaste?

¡Indexar claves foráneas!

Tal vez esto no sea una optimización de sintaxis de consulta SQL, sino más bien una optimización de almacenamiento. Pero veo que vuelve a ocurrir todo el tiempo y es un motivo favorito.

indexa es la optimización más común
De normalizar las tablas.
Eliminar restricciones (solo si sabes lo que estás haciendo)

1) Todavía tengo que encontrar una situación donde

SELECT Field1, Field2, (SELECT Count(*) FROM tblLinked WHERE tblLinked.Field3 = tblSource.Field3) AS TheTotal FROM tblSource

no se mejora con una UNIÓN IZQUIERDA a una tabla derivada.

SELECT Field1, Field2, IsNull(Linked.TheTotal,0) AS TheTotal FROM tblSource LEFT JOIN (SELECT Field3, Count(*) AS TheTotal FROM tblLinked GROUP BY Field3) AS Linked ON tblSource.Field3 = Linked.Field3

2) No ordene los resultados en el servidor a menos que la aplicación consumidora no pueda hacerlo por sí misma. Esto se aplica con menos frecuencia a las aplicaciones web, pero para las aplicaciones de escritorio, la PC del cliente generalmente tiene mucha potencia disponible y puede hacer cualquier cosa.

3) Use EXISTS en lugar de verificar el conteo de entradas coincidentes.

4) No te obsesiones con hacer una consulta en una sola cláusula SELECT. El uso juicioso de las variables de la tabla (y algunas veces de las tablas temporales) puede reducir masivamente las filas procesadas.

Almacenamiento en caché de salida db. Evitar presionar la base de datos parece ser una optimización prudente.

+1 memcached.

Asegurándose de que las tablas se unan en el orden correcto.

Disminuir los niveles de aislamiento de las transacciones para evitar los bloqueos de las tablas de las consultas de los usuarios. No todo el tiempo, pero para que Gui muestre información general funciona muy bien.

Evite el uso de funciones incorporadas como convertdate, stringreplace y tal en sus Vistas. Si no puede asegurarse de que los datos estén en un formato válido, use los procedimientos almacenados que se ejecutan reguallary para ''limpiar'' los datos en sus tablas relevantes.

esto es desagradable, pero guarda el tiempo de las vistas, es decir, mantiene al usuario feliz ... ^^

He leído todas las respuestas y no encontré sugerencias de uso LIMIT y OFFSET. Es un uso muy común en la paginación con enlaces "prev" y "siguiente". Pero renderizar dicha pantalla puede consumir más recursos que el resto del sitio. Cuando se compensan ítems de gran número, la consulta puede volverse muy lenta. Así que evita estas consultas.

No cuente el total de elementos.
Muestre solo los primeros elementos del número "n" (por ejemplo, solo los 100 primeros).

Dichos métodos usan Google, Twitter y otros sitios. En la búsqueda de Google no hay una cantidad exacta de resultados. Solo hay un número aproximado. Twitter no permite al usuario ver todos los tweets anteriores. Muestra solo el último n número (no recuerdo cuánto).

Hay algún enlace del blog de rendimiento de MySQL .

La mejor optimización que he tenido con SQL fue entender realmente qué se necesitaba para hacer los datos y QUITAR toneladas de SQL de la consulta.

La consulta más rápida es la consulta que no debe ejecutarse.

REALMENTE PIENSA sobre lo que estás haciendo con los datos. ¿Estás trabajando fila por fila? (luego use el código basado en el set)

¿De verdad necesitas unirte a todas esas tablas?
¿Pueden dos consultas pequeñas (simples) hacer el trabajo mejor y más rápido que una sola consulta grande?
Si combina estas dos consultas en una sola consulta, ¿puede ejecutarse más rápido?

Finalmente, PERFILA tus consultas (EXPLICA PLAN o SQL PROFILER) y mira "IO gets". En general, desea reducir el número de GET a una proporción de aproximadamente 10 por cada fila de salida.

Las dos cosas más importantes en mi experiencia son menos combinaciones y menos consultas. Aparte de esos, hay un montón de cosas específicas de DB, COUNT (*) es relativamente lento en PgSQL, subselects son dog slow en MySQL, etc.

Las optimizaciones más grandes que utilicé recientemente son bastante simples.

Mantenga la mayor parte de la lógica comercial lo más cerca posible del servidor sql. Aka guarda tu código comercial en la misma máquina que el servidor sql. Deje que su lógica empresarial devuelva lo menos posible el código al cliente final.

Mantenga su consulta SQL tan "corta como sea posible", como dijo Frost, use declaraciones de actualización únicas en varias declaraciones.

Solo usa transacciones cuando las necesites

Cree tablas temporales para combinaciones parciales para acelerar las uniones (no olvide indexarlas)

Mi lista de consejos favoritos (explicada en detalle aquí) es la siguiente

Intente restringir el conjunto de resultados de consultas utilizando la cláusula WHERE.
Intente restringir el conjunto de resultados de consultas devolviendo solo las columnas particulares de la tabla, no todas las columnas de la tabla.
Use vistas y procedimientos almacenados en lugar de consultas pesadas.
Siempre que sea posible, trate de evitar el uso de cursores de SQL Server.
Si necesita devolver el recuento total de filas de la tabla, puede usar una forma alternativa en lugar de la instrucción SELECT COUNT (*).
Intente utilizar restricciones en lugar de desencadenantes, siempre que sea posible.
Use variables de tabla en lugar de tablas temporales.
Intenta evitar la cláusula HAVING, siempre que sea posible.
Siempre que sea posible, trate de evitar el uso de la cláusula DISTINCT.
Incluya la instrucción SET NOCOUNT ON en sus procedimientos almacenados para detener el mensaje que indica el número de filas afectadas por una instrucción T-SQL.
Utilice declaraciones seleccionadas con la palabra clave TOP o la declaración SET ROWCOUNT si necesita devolver solo las primeras n filas.
Use la sugerencia de la tabla FAST number_rows si necesita devolver rápidamente las filas de ''number_rows''.
Intenta usar la declaración UNION ALL en lugar de UNION, siempre que sea posible.
No use sugerencias de optimizador en sus consultas.

No aplique restricciones si no es necesario, ya que las restricciones agregarán un índice, mientras más números haya, más tiempo llevará la inserción de datos.

Par de pistas: uso

delete from table where id>=1 and id<=3;

en lugar de

delete from table where id=1; delete from table where id=2; delete from table where id=3;

También use la sintaxis ''IN'' en lugar de ''OR''

Por encima y por encima: Hacer índices de cobertura

Un índice de cobertura incluye todas las columnas que necesitará la consulta, evitando así la necesidad de realizar búsquedas en los resultados de una búsqueda de índice. Esto evitará que el sistema sienta que un escaneo podría ser más rápido (lo que es notablemente rápido teniendo en cuenta el costo de las búsquedas).

Pero también vale la pena mencionar:

Tener un índice que permita una fusión unirse. Una unión MERGE puede ocurrir al unir dos tablas ordenadas por las condiciones de unión. Pero, por supuesto, al decir ''tabla'', realmente queremos decir ''índice'', ¿verdad?

Además, eliminar funciones escalares y usar funciones con valores de tabla en su lugar ... ya que las funciones escalares no se pueden simplificar.

Además, al colocar un índice único en una columna que usted sabe que es único, permite que el optimizador de consultas use este conocimiento para tomar mejores decisiones de optimización. También se aplica a las restricciones NOT NULL.

Además, se utiliza la intercalación binaria al comparar cadenas que se encuentran en un caso conocido, de modo que el sistema no tiene que considerar las diferentes opciones de casos.

Por supuesto, podría seguir todo el día ...

Robar

Reducir la cantidad de datos que se devuelven, solo devolviendo los campos requeridos y solo devolviendo las filas requeridas. Este es el más común, ya que lo hace por cada consulta que devuelve datos.

Agregar índices Esto no se realiza con la frecuencia, ya que algunas tablas no necesitan ningún otro índice que el creado para la clave principal.

Si estás hablando en común como en común, entonces los índices son lo primero que aparece en mi cabeza.

Son una técnica poderosa que a menudo se malinterpreta y con bastante frecuencia se abusa.

Luego colocaría la des-normalización que puede agregar bastante rendimiento para muchas bases de datos.

La optimización de consultas es la tercera y ayuda mucho también. Uso MySQL estos días y el registro de consultas ayuda mucho para la optimización.

Memcached definitivamente no es común, aunque el almacenamiento en caché de algún tipo es una parte de muchos sitios web en el extremo de scripting (ASP.Net o PHP).