¿Qué puede causar un mal rendimiento del servidor SQL?

Question

Cada vez que descubro que el rendimiento de la recuperación de datos de mi base de datos es lento. Intento averiguar qué parte de mi consulta SQL tiene el problema y trato de optimizarlo y también agregar algunos índices a la tabla. Pero esto no siempre resuelve el problema.

Mi pregunta es:

¿Hay otros trucos para hacer que el rendimiento del servidor SQL mejor?

¿Cuál es el otro motivo que puede empeorar el rendimiento del servidor SQL?

Answer 1

• consulta ineficiente diseño
• archivos auto-crecimiento
• Demasiados índices que se deben mantener en una mesa
• Muy pocos índices en una tabla
• no elegir correctamente su índice agrupado
• Índice fragmentación debido a mantenimiento deficiente
• Fragmentación del montón debido a que no hay índice agrupado
• demasiado altas FILLFACTORs utilizan en índices, causando página excesiva división
• demasiado baja de un FILLFACTOR utilizado en índices, haciendo que el uso de espacio excesivo y el aumento de tiempo de exploración
• No usar índices cubiertos donde se utilizan apropiados
• índices no selectivos
• mantenimiento inadecuado de las estadísticas (de estadísticas actualizadas)
• bases de datos no normalizada correctamente
• los registros de transacciones y datos que comparten los mismos ejes de accionamiento
• La memoria incorrecta configuración
• muy poca memoria
• nivel demasiado bajo de CPU
• lentos discos duros
• que fallan los discos duros u otro hardware
salvapantallas
• Un 3D en el servidor de base de datos de masticar su CPU
• Sharing el servidor de la base de datos con otros procesos que compiten por CPU y memoria
• Conflicto de bloqueo entre consultas
• Consultas que escanean todo grandes mesas
• código de fin delantero que busca en los datos de una manera inefficent (bucles anidados, fila por fila)
• CURSORS que no son necesarios y/o no son FAST_FORWARD
• No establecer NOCOUNT cuando haya grandes mesas que cursored mediante.
• El uso de un nivel de aislamiento que es demasiado alto (como el uso SERIALIZABLE cuando no es necesario)
• Demasiados viajes de ida y vuelta entre el cliente y el servidor SQL Server (una interfaz hablador)
• una consulta innecesaria servidor vinculado
• una consulta de servidor vinculado que se dirige a una mesa en un servidor remoto sin llave primaria o candidato definido
• Selección demasiados datos
• recopilaciones de consulta excesivas

oh y podría haber algunos otros también.

Answer 2

Si es nuevo en la base de datos y tiene acceso al asesor de ajuste del motor de la base de datos, puede ajustar su base de datos de manera heurística.

Básicamente captura las consultas SQL que se ejecutan contra su base de datos en el Analizador de SQL, y luego las envía a DETA. DETA ejecuta de manera efectiva las consultas (sin alterar sus datos) y luego resuelve qué información falta en su base de datos (vistas, índices, particiones, estadísticas, etc.) para hacer las consultas mejor.

Puede aplicarlos y supervisarlos en el futuro. No estoy diciendo que supongo que DETA siempre tiene la razón o que hago cosas sin entender, pero he descubierto que definitivamente es una buena forma de ver qué hacen sus consultas, cuánto tiempo toman y cómo puede indexar la base de datos. adecuadamente.

PD: Con todo lo dicho, es mucho mejor invertir en un buen DBA al inicio de un proyecto para que tenga buenas estructuras e indexación para empezar. Pero esa no es la posición en la que se encuentra ahora ...

Answer 3

Cuando hablo con nuevos desarrolladores que tienen este problema, generalmente encuentro que es debido a uno de dos problemas. Ambos están corregidos si sigues estas 2 reglas.

Primero, no recupere ningún dato que no necesite. Por ejemplo, si está realizando una búsqueda, no devuelva 100 filas y luego calcule cuáles pertenecen a la página. Haz que el proceso almacenado lo resuelva y solo recupere los 10 que necesitas.

En segundo lugar, nada es más rápido que el trabajo que no hace. Por ejemplo, trabajé en un sistema en el que se recuperaban las funciones y los derechos completos de un usuario con cada página solicitada: eran cientos de filas para algunos usuarios. Incluso el solo hecho de guardar esto en el estado de la sesión en la primera solicitud y luego usarlo desde allí para las solicitudes posteriores quitó un peso significativo de la base de datos.

Answer 4

Le sugerimos que obtenga un buen libro sobre la optimización del rendimiento de la base de datos que utiliza (esto es mucho más específico de la base de datos). Este es un tema extremadamente complejo y no puede ser respondido de otra manera que en generalidades en la web.

Por ejemplo, Dave markle dice que las consultas ineficaces pueden causar el problema y hay muchas formas de escribir consultas ineficaces y muchas más formas de solucionarlas.

Answer 5

Esta es una pregunta muy amplia. Y ya hay un montón de respuestas. Sin embargo, me gustaría agregar un factor importante: Page Split. El problema es que hay buenas divisiones y malas divisiones.Los siguientes son buenos artículos que explican cómo utilizar transaction_log extendida de eventos para identificar página dañada/desagradable divide

1. Tracking Problematic Pages Splits in SQL Server 2012 Extended Events - Jonathan Kehayias
2. Tracking page splits using the transaction log - Paul Randal

Usted mencionó:

Trato de optimizarlo y también agregue algunos índices

Pero, a veces, la eliminación de índices no agrupados no utilizados puede ayudar a mejorar el rendimiento, ya que ayuda a reducir los registros de transacciones. Lee Top Reasons for Log Performance Problems

Wait statistics, or please tell me where it hurts da una idea sobre el uso de estadísticas de espera para el análisis del rendimiento.

Para ver algunas ideas frescas para el rendimiento, echar un vistazo a Performance Considerations - sqlmag.com

1. mesas separadas en las combinaciones de diferentes discos (para el disco paralelo de E/S - grupos de archivos).
2. Evite las uniones en columnas con pocos valores únicos.

Para entender JOIN, leer Advanced JOIN Techniques