Trucos de ajuste de rendimiento favoritos

Aquí está la lista práctica de cosas que siempre le doy a alguien que me pregunta sobre la optimización.
Usamos principalmente Sybase, pero la mayoría de los consejos se aplicarán en todos los ámbitos.

SQL Server, por ejemplo, viene con una gran cantidad de bits de control/ajuste del rendimiento, pero si no tiene nada de eso (y tal vez incluso si lo tiene), entonces consideraría lo siguiente...

99 % de los problemas He visto que son causadas por poner demasiadas tablas en una unión . La solución para esto es hacer la mitad de la unión (con algunas de las tablas) y almacenar en caché los resultados en una tabla temporal. Luego haga el resto de la consulta uniéndose a esa tabla temporal.

Lista de verificación de optimización de consultas

• Ejecute UPDATE STATISTICS en las tablas subyacentes
  • Muchos sistemas ejecutan esto como un trabajo semanal programado
• Eliminar registros de las tablas subyacentes (posiblemente archivar los registros eliminados)
  • Considere hacer esto automáticamente una vez al día o una vez a la semana.
• Reconstruir índices
• Reconstruir tablas (salida/entrada de datos bcp)
• Volcar/recargar la base de datos (drástico, pero podría corregir la corrupción)
• Crear un índice nuevo y más apropiado
• Ejecute DBCC para ver si existe una posible corrupción en la base de datos
• Bloqueos/Interbloqueos
  • Asegúrese de que no se ejecuten otros procesos en la base de datos
    • Especialmente DBCC
  • ¿Está utilizando el bloqueo a nivel de fila o de página?
  • Bloquear las tablas exclusivamente antes de iniciar la consulta
  • Compruebe que todos los procesos acceden a las tablas en el mismo orden
• ¿Se utilizan los índices de forma adecuada?
  • Las uniones solo usarán el índice si ambas expresiones son exactamente del mismo tipo de datos
  • El índice solo se utilizará si los primeros campos del índice coinciden en la consulta
  • ¿Se utilizan índices agrupados cuando corresponde?
    • datos de rango
    • campo DONDE entre valor1 y valor2
• Las uniones pequeñas son buenas uniones
  • De forma predeterminada, el optimizador solo considerará las tablas 4 a la vez.
  • Esto significa que en uniones con más de 4 tablas, tiene buenas posibilidades de elegir un plan de consulta no óptimo
• Dividir la unión
  • ¿Puedes romper la unión?
  • Preseleccionar claves foráneas en una tabla temporal
  • Haga la mitad de la combinación y coloque los resultados en una tabla temporal
• ¿Está utilizando el tipo correcto de tabla temporal?
  • #temp las tablas pueden funcionar mucho mejor que @table variables con grandes volúmenes (miles de filas).
• Mantener tablas de resumen
  • Crear con disparadores en las tablas subyacentes
  • Construir diariamente / por hora / etc.
  • Crear ad-hoc
  • Construir de forma incremental o desmontar/reconstruir
• Vea cuál es el plan de consulta con SET SHOWPLAN ON
• Vea lo que está sucediendo realmente con SET STATS IO ON
• Forzar un índice usando el pragma:(index:myindex)
• Fuerza el orden de la mesa usando SET FORCEPLAN ON
• Análisis de parámetros:
  • Dividir el procedimiento almacenado en 2
  • llamar a proc2 desde proc1
  • permite que el optimizador elija el índice en proc2 si @parameter ha sido cambiado por proc1
• ¿Puedes mejorar tu hardware?
• ¿A qué hora corres? ¿Hay un momento más tranquilo?
• ¿Se está ejecutando el servidor de replicación (u otro proceso ininterrumpido)? ¿Puedes suspenderlo? Ejecutarlo, por ejemplo. ¿cada hora?