2010-04-25 6 views
12

Podemos obtener una lista de las técnicas de optimización básicas (desde modelado hasta consultas, creación de índices, vistas para optimización de consultas). Sería bueno tener una lista de estos, una técnica por respuesta. Como aficionado, me parece que es muy útil, gracias.Técnicas de optimización de bases de datos para amateurs

Y por no ser demasiado vagos, digamos que estamos utilizando una base de datos maintstream como MySQL u Oracle, y que la base de datos contendrá 500,000-1m o más registros en ~ 10 tablas, algunas con restricciones de claves externas , todos usan los motores de almacenamiento más típicos (p. ej .: InnoDB for MySQL). Y, por supuesto, se definen los conceptos básicos, como los PK, así como las restricciones de FK.

+0

Wiki de la comunidad? –

+0

muy buena pregunta. –

+1

Ojalá obtuviera más respuestas. – Zombies

Respuesta

14

Obtenga información acerca de los índices y úselos correctamente. En términos generales *, siga estas pautas:

  • Cada tabla debe tener un índice agrupado
  • Campos empleados para filtros y ordenaciones son buenos candidatos para la indexación
  • Más selectivos campos son mejores candidatos para la indexación
  • Para obtener el mejor rendimiento en consultas cruciales, diseñe "cubriendo índices" para esas consultas
  • Asegúrese de que sus índices estén siendo utilizados en realidad, y elimine los que no son
  • Si la tabla tiene 15 campos, y usted hace 15 índices, cada uno con un único campo, lo estás haciendo mal :)

* Hay algunas excepciones a estas reglas si usted sabe lo que está haciendo Mi experiencia es Microsoft SQL Server, pero supongo que la mayoría de estos consejos se seguirían aplicando a un RDMS diferente.

+0

Se deben tener precauciones al usar índices agrupados en una tabla que podría agrandarse. Cuando inserta o actualiza una fila, es posible que el índice agrupado pueda causar un reordenamiento de la tabla que podría suponer un golpe de rendimiento. –

5

Al hablar sobre el diseño de la base de datos, verifique la normalización de la base de datos, p. el artículo de wikipedia: Normal forms.

Si tiene un buen diseño y aún necesita optimizar el rendimiento, intente Denormalisation.

Si tiene necesidades específicas que no están cubiertas por el modelo relacional de manera eficiente, consulte otros modelos cubiertos por el término NoSQL.

+0

Este es un consejo fantástico: ¡la normalización NO siempre es la respuesta! – Timothy

7

IMO, de lejos, la mejor optimización es que el modelo de datos se ajuste al dominio del problema para el que se creó. Cuando no es así, el síntoma resultante es una consulta difícil de escribir o complicada para obtener la información deseada y que normalmente se remonta a sí misma cuando se generan informes en la base de datos. Por lo tanto, al diseñar una base de datos, ayuda a tener una idea de los tipos y la naturaleza de la información, como los informes, que los usuarios querrán del sistema.

+0

'sistema resultante' ¿quizás? ¿No es 'síntoma resultante'? – MJB

+1

@MJB - Creo que lo indiqué correctamente. ¿Cómo sabe que el modelo de datos no se ajusta al dominio del problema? Los síntomas son complicados o difíciles de escribir. – Thomas

+0

Ya veo. Leí mal. Pensé que estabas diciendo "el sistema resultante es difícil de escribir", y ahora veo que querías decir "el síntoma resultante es difícil de escribir consultas". Mi error. Pensé que era un error tipográfico. – MJB

2

Un diseño que concisamente modele su problema siempre es un buen comienzo. La generalización excesiva del modelo de datos puede provocar problemas de rendimiento. Por ejemplo, he escuchado informes de proyectos que luchan por una flexibilidad superior que usa el RDBMS como una tonta tienda de "nombre/valor", y el rendimiento resultante fue espantoso.

Una vez que se ha implementado un buen diseño, utilice las herramientas proporcionadas por el RDBMS para lograr un buen rendimiento. Campo único PKs (sin compuestos), pero las claves empresariales compuestas como un índice con restricción única, uso de tipos de datos apropiados, p. utilizando los tipos numéricos apropiados para valores numéricos en lugar de char o similar.También se deben tener en cuenta los atributos físicos del hardware en el que se ejecuta el RDBMS, ya que la mayor parte del tiempo de consulta suele ser de E/S de disco, pero por supuesto no se lo da por sentado. Utilice un generador de perfiles para saber a dónde va el tiempo. .

Dependiendo de la relación actualización/consulta, las vistas materializadas/vistas indexadas pueden ser útiles para mejorar el rendimiento de las consultas de ejecución lenta. La alternativa de un pobre es usar desencadenantes para invocar un procedimiento que rellena la tabla con el resultado de una vista de ejecución lenta y poco cambiada.

La optimización de consultas es un poco de arte negro, ya que a menudo depende de la base de datos, pero algunas reglas generales se dan aquí - Optimizing SQL.

Finalmente, aunque posiblemente fuera del alcance previsto de su pregunta, utilice una buena capa de acceso a datos en su aplicación y evite la tentación de implementar la suya propia; seguramente existen implementaciones probadas y disponibles para todos los idiomas principales. El uso del almacenamiento en caché en la capa de acceso a datos, nivel medio y capa de aplicación puede ayudar a mejorar el rendimiento considerablemente.

3

Algunas optimizaciones de consultas/esquema:

  • ser consciente cuando se utiliza DISTINCT o GROUP BY. Encuentro que muchos desarrolladores nuevos usarán DISTINCT en lugares donde realmente no es necesario o podrían reescribirse más eficientemente utilizando una declaración Exists o una consulta derivada.

  • Tenga en cuenta que Left Joins. Con demasiada frecuencia encuentro que los nuevos desarrolladores de SQL ignorarán el esquema en su lugar y usarán las uniones izquierdas donde realmente no son necesarios. Por ejemplo:

Select 
From Orders 
    Left Join Customers 
     On Customers.Id = Orders.CustomerId

Si Orders.CustomerID es una columna requerida, entonces no es necesario el uso de una combinación izquierda.

  • Sea un estudiante de nuevas funciones. Actualmente, MySQL no admite expresiones de tabla común, lo que significa que algunos tipos de consultas son engorrosas y probablemente más lentas de lo que serían si se admitieran CTE. Sin embargo, eso no será verdad para siempre. Manténgase al día sobre las nuevas características de sintaxis en MySQL que podrían usarse para hacer las consultas existentes más eficientes.

  • No tiene que usar claves sustitutivas en todas partes. Puede haber tablas más adecuadas para una clave inteligente (por ejemplo, abreviaturas de Estados Unidos, códigos de moneda, etc.) que permitirían a los desarrolladores evitar uniones adicionales en muchos casos.

  • Si es posible, busque formas de archivar datos en un OLAP o servidor de informes. Cuanto más pequeño pueda hacer los datos de producción, más rápido se ejecutará.

0

Adopte un enfoque holístico para la optimización.

Tenga en cuenta el impacto de los discos lentos, la latencia de la red, la falta de memoria y la carga del servidor.

1

Utilice menos consulta siempre que sea posible. Use "JOIN" y agrupe sus tablas para que una sola consulta dé sus resultados.

Un buen ejemplo es el Modificado Preordenes árbol transversal (MPTT) para obtener todos los padres un nodo del árbol, ordenada, en una sola consulta.

Cuestiones relacionadas