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

Question

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

Answer 1

Reduciendo 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.

Agregando í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.

Answer 2

1. índices de optimización de su la más común
2. De la normalización de las tablas.
3. eliminación de las restricciones (sólo si sabe lo que está haciendo)

Answer 3

La reducción de los niveles de aislamiento de transacción para moverse por bloqueos de tabla de consultas de los usuarios. No todo el tiempo, pero para que Gui muestre información general funciona muy bien.

Answer 4

Caching db output. Evitar presionar la base de datos parece ser una optimización prudente.

+1 memcached.

Answer 5

Si hablas en común como en común, los índices son lo primero que me viene a la 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).

Answer 6

Mi lista de favoritos de tips (explained in detail here) es el siguiente

1. tratar de restringir las consultas de conjunto de resultados mediante el uso de la cláusula WHERE.
2. Intenta restringir el conjunto de resultados de las consultas devolviendo solo las columnas particulares de la tabla, no todas las columnas de la tabla.
3. Utilice vistas y procedimientos almacenados en lugar de consultas de servicio pesado.
4. Siempre que sea posible, intente evitar el uso de cursores de SQL Server.
5. Si necesita devolver el recuento total de filas de la tabla, puede usar una forma alternativa en lugar de la instrucción SELECT COUNT (*).
6. Trate de usar restricciones en lugar de desencadenantes, siempre que sea posible.
7. Utilice variables de tabla en lugar de tablas temporales.
8. Trate de evitar la cláusula HAVING, siempre que sea posible.
9. Siempre que sea posible, trate de evitar el uso de la cláusula DISTINCT.
10. 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.
11. Utilice las instrucciones seleccionadas con la palabra clave TOP o la declaración SET ROWCOUNT si necesita devolver solo las primeras n filas.
12. Utilice la sugerencia de la tabla FAST number_rows si necesita devolver rápidamente las filas de 'number_rows'.
13. Intente utilizar la declaración UNION ALL en lugar de UNION, siempre que sea posible.
14. No utilice consejos de optimizador en sus consultas.

Answer 7

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

Answer 8

1) todavía tengo que encontrar una situación en la que

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

no mejora con un LEFT JOIN 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 recuento de entradas coincidentes.

4) No se obsesione 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.

Answer 9

Con mucho, y por encima de: Realización de índices que cubren

Un índice de cobertura incluye todas las columnas que va a necesitar la consulta, evitando así la necesidad de realizar búsquedas sobre 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 combinación de mezcla. 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', a la derecha ...

También se eliminan las funciones escalares y las funciones con valores de tabla en su lugar ... ya que las funciones escalares no se pueden simplificar .

También: colocando un índice único en una columna que sabe que es única, lo que permite que el optimizador de consultas utilice este conocimiento para tomar mejores decisiones de optimización. También se aplica a las restricciones NOT NULL.

También: se utiliza la intercalación binaria al comparar cadenas que están en un caso conocido, por lo que el sistema no tiene que considerar las diferentes opciones de casos.

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

Rob

Answer 10

Las dos cosas más importantes en mi experiencia son menos uniones 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.

Answer 11

par de consejos: 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 utilice 'EN' en lugar de 'O' sintaxis

Answer 12

Los mayores optimizaciones Recientemente he usado en muy simple .

Mantenga la mayor lógica de negocios 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.

Utilice únicamente las transacciones cuando los necesite

Crear tablas temporales para la combinación parcial para acelerar las uniones (no se olvide de indexarlos)

Answer 13

He leído todas las respuestas y yo no fundó LIMIT y Indicaciones de uso 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.
• Mostrar solo los primeros elementos del número "n" (por ejemplo, solo los 100 principales).

Dichos métodos utilizan 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 algunos link from MySQL performance blog.

Answer 14

¡Claves foráneas de índice!

Tal vez esto no es una optimización de la sintaxis de consultas SQL, sino más bien una optimización del almacenamiento. Pero veo que vuelva a ocurrir todo el tiempo de su & una manía.

Answer 15

La mejor optimización que he tenido con SQL fue entender realmente lo que 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.

pensar realmente en lo que estás haciendo a los datos. ¿Estás trabajando fila por fila? (luego use el código basado en el set)

• ¿Realmente necesita unirse 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, ¿se puede ejecutar 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.

Answer 16

Evite el uso de funciones incorporadas como convertdate, stringreplace y demás en sus Vistas. Si no puede asegurarse de que los datos están en un formato válido procedimientos de utilización almacenados que se ejecutan reguallary para 'limpiar' los datos de las tablas pertinentes.

esto es desagradable, pero se ahorra el tiempo es decir, puntos de vista mantiene al usuario feliz ... ^^

Answer 17

No ponga restricciones si no es requerido como restricciones agregará un índice, el mayor número de índices, el más el tiempo que lleva insertar los datos