optimizar - plan de ejecución y optimización de consultas sql server 2008 r2

¿Cómo se optimizan las tablas para consultas específicas? (9)

¿Cuáles son los patrones que usa para determinar las consultas frecuentes?
¿Cómo se seleccionan los factores de optimización?
¿Cuáles son los tipos de cambios que uno puede hacer?

Para MySQL hay una característica llamada log slow queries

El resto se basa en qué tipo de datos tiene y cómo está configurado.

índices de PK y FK y una cosa que siempre ayuda a PARTICIONAR ...

En el servidor SQL, puede usar el rastreo para descubrir el rendimiento de su consulta. Use ctrl + k o l

Por ejemplo, si observa que la exploración de tabla completa está sucediendo en una tabla con una gran cantidad de registros, probablemente no sea una buena consulta.

Una pregunta más específica definitivamente te traerá mejores respuestas.

Es difícil de responder sin saber de qué sistema estás hablando.

En Oracle, por ejemplo, Enterprise Manager le permite ver qué consultas ocuparon la mayor cantidad de tiempo, le permite comparar diferentes perfiles de ejecución y le permite analizar consultas en un bloque de tiempo para que no agregue un índice que ayude una consulta a expensas de cada uno que ejecute.

Mi experiencia es principalmente con DB2 y algunos conceptos de Oracle en los primeros días.

Si su DBMS es bueno, tendrá la capacidad de recopilar estadísticas sobre consultas específicas y explicar el plan que utilizó para extraer los datos.

Por ejemplo, si tiene una tabla (x) con dos columnas (fecha y disquete) y solo tiene un índice de fecha, la consulta:

select diskusage from x where date = ''2008-01-01''

será muy eficiente ya que puede usar el índice. Por otro lado, la consulta

select date from x where diskusage > 90

no sería tan eficiente. En el primer caso, el "plan de explicación" le indicaría que podría usar el índice. En este último, habría dicho que tenía que hacer un escaneo de tabla para obtener las filas (que básicamente es mirar cada fila para ver si coincide).

El DBMS realmente inteligente también puede explicar lo que debe hacer para mejorar el rendimiento (agregue un índice de disipación en este caso).

En cuanto a cómo ver qué consultas se están ejecutando, puede recopilar eso desde el DBMS (si lo permite) o forzar a todos a hacer sus consultas a través de procedimientos almacenados para que el DBA controle cuáles son las consultas: ese es su trabajo, manteniendo el DB funcionando eficientemente

Si su tabla es predominantemente leída, coloque un índice agrupado en la tabla.

Tu pregunta es un poco vaga ¿Qué plataforma DB?

Si estamos hablando de SQL Server:

Use las vistas de administración dinámica. Use el Analizador de SQL. Instale el SP2 y los informes del tablero de rendimiento.
Después de determinar las consultas más costosas (es decir, el número de veces que ejecuta x cuesta una consulta), examine sus planes de ejecución y observe los tamaños de las tablas involucradas, y si son predominantemente de lectura o escritura, o una mezcla de ambos.
Si el sistema está bajo su control total (aplicaciones y bases de datos), a menudo puede volver a escribir consultas mal formadas (una ocurrencia bastante común), como subconsultas profundamente correlacionadas que a menudo pueden reescribirse como combinaciones derivadas de tablas. con un poco de pensamiento De lo contrario, las opciones son crear índices de cobertura no agrupados y garantizar que las estadísticas se mantengan actualizadas.

1. ¿Cuáles son los patrones que usa para determinar las consultas frecuentes?

Depende del nivel con el que estés tratando la base de datos. Si es un administrador de bases de datos o tiene acceso a las herramientas, las bases de datos como Oracle le permiten ejecutar trabajos y generar estadísticas / informes en un período de tiempo específico. Si eres un desarrollador que escribe una aplicación en una base de datos, puedes hacer perfiles de rendimiento dentro de tu aplicación.

2. ¿Cómo se seleccionan los factores de optimización?

Intento obtener una idea general de cómo se usa la tabla y los datos que contiene. Voy con las siguientes preguntas.

¿Se actualizará muchísimo y en qué campos se realizarán las actualizaciones? ¿Tiene columnas con baja cardinalidad?

¿Vale la pena indexar? (Las tablas que son muy pequeñas se pueden ralentizar si se accede por un índice)

¿Cuánto mantenimiento / dolor de cabeza merece la pena para que funcione más rápido?

Relación de actualizaciones / inserciones vs consultas?

etc.

3. ¿Cuáles son los tipos de cambios que uno puede hacer?

- Si usa Oracle, ¡mantenga las estadísticas actualizadas! =)

- Normalización / Des-Normalización cualquiera puede mejorar el rendimiento dependiendo del uso de la tabla. Casi siempre me normalizo y solo si no puedo de ninguna otra manera práctica hacer la consulta más rápido se desnormalizará. Una buena forma de desnormalizar las consultas y cuando su situación lo permita es mantener las tablas reales normalizadas y crear una "tabla" desnormalizada con una vista materializada.

- Index juiciosamente. Demasiados pueden ser malos en muchos niveles. Los índices de BitMap son geniales en Oracle siempre que no actualice la columna con frecuencia y esa columna tenga una cardinalidad baja.

- Uso de tablas organizadas de índice.

- Tablas e índices particionados y sub-particionados

- Utilice procedimientos almacenados para reducir los viajes redondos por las aplicaciones, aumentar la seguridad y habilitar la optimización de consultas sin afectar a los usuarios.

- Pin tablas en la memoria si es apropiado (se accede mucho y bastante pequeño)

- Partición de dispositivo entre archivos de base de datos de índices y tablas.

..... la lista continua. =)

Espero que esto te ayude.

Esta es una buena pregunta, si es bastante amplia (y ninguna es peor para eso).
Si te entiendo, entonces estás preguntando cómo atacar el problema de la optimización comenzando desde cero.

La primera pregunta es: " ¿hay algún problema de rendimiento? "
Si no hay problema, entonces has terminado. Este es a menudo el caso. Bonito.

Por otra parte...

Determinar consultas frecuentes

El registro le dará sus consultas frecuentes.
Si está utilizando algún tipo de capa de acceso a datos, entonces puede ser simple agregar código para registrar todas las consultas.
También es una buena idea iniciar sesión cuando se ejecutó la consulta y cuánto tarda cada consulta. Esto puede darte una idea de dónde están los problemas.
Además, pregunte a los usuarios qué bits les molestan. Si una respuesta lenta no molesta al usuario, entonces no importa.

Seleccione los factores de optimización?

(Puedo malinterpretar esta parte de la pregunta). Está buscando patrones en las consultas / tiempos de respuesta.
Normalmente, se tratará de consultas sobre tablas o consultas de gran tamaño que unen muchas tablas en una sola consulta. ... pero si registra tiempos de respuesta, puede ser guiado por ellos.

Tipos de cambios que uno puede hacer?

Estás preguntando específicamente sobre la optimización de tablas.
Estas son algunas de las cosas que puede buscar:

Denormalización . Esto reúne varias tablas en una tabla más amplia, por lo que en lugar de su consulta, uniendo varias tablas, puede leer una sola tabla. Esta es una técnica muy común y poderosa. NÓTESE BIEN. Aconsejo mantener las tablas originales normalizadas y construir la tabla desnormalizada además, de esta forma, no estás tirando nada. Cómo lo mantienes actualizado es otra pregunta. Puede usar activadores en las tablas subyacentes o ejecutar un proceso de actualización periódicamente.
Normalización . Esto a menudo no se considera un proceso de optimización, pero es en 2 casos:
- actualizaciones. La normalización hace que las actualizaciones sean mucho más rápidas porque cada actualización es lo más pequeña que puede ser (está actualizando la tabla más pequeña posible, en términos de columnas y filas. Esta es casi la definición misma de normalización.
- Consultar un cuadro desnormalizado para obtener información que existe en una tabla mucho más pequeña (menos filas) puede estar causando un problema. En este caso, almacene la tabla normalizada así como la denormalizada (vea arriba).
Partición horizontal . Esto significa hacer las tablas más pequeñas al colocar algunas filas en otra tabla idéntica. Un caso de uso común es tener todas las filas de este mes en la tabla ThisMonthSales , y todas las filas anteriores en la tabla OldSales , donde ambas tablas tienen un esquema idéntico. Si la mayoría de las consultas son para datos recientes, esta estrategia puede significar que el 99% de todas las consultas solo miran el 1% de los datos, una gran ganancia de rendimiento.
Partición vertical . Esto es Cortar campos de una tabla y colocarlos en una nueva tabla que se une a la tabla principal mediante la clave principal. Esto puede ser útil para tablas muy amplias (por ejemplo, con docenas de campos), y puede ayudar si las tablas están poco pobladas.
Indecis . No estoy seguro de si su pregunta abarca estos, pero hay muchas otras respuestas sobre SO sobre el uso de indeces. Una buena forma de encontrar un caso para un índice es encontrar una consulta lenta. mira el plan de consulta y encuentra un escaneo de tabla. Indique los campos en esa tabla para eliminar la exploración de la tabla. Puedo escribir más sobre esto si es necesario, dejar un comentario.

También te puede interesar mi publicación sobre esto .