Astuces de réglage des performances préférées

Voici la liste pratique des choses que je donne toujours à quelqu'un qui me pose des questions sur l'optimisation.
Nous utilisons principalement Sybase, mais la plupart des conseils s'appliqueront à tous.

SQL Server, par exemple, est livré avec une foule de bits de surveillance/réglage des performances, mais si vous n'avez rien de tel (et peut-être même si vous en avez), alors je considérerais ce qui suit...

99 % des problèmes J'ai vu sont causés par le fait de mettre trop de tables dans une jointure . La solution consiste à effectuer la moitié de la jointure (avec certaines tables) et à mettre en cache les résultats dans une table temporaire. Ensuite, effectuez le reste de la requête en joignant cette table temporaire.

Liste de contrôle pour l'optimisation des requêtes

• Exécuter UPDATE STATISTICS sur les tables sous-jacentes
  • De nombreux systèmes l'exécutent comme une tâche hebdomadaire planifiée
• Supprimer les enregistrements des tables sous-jacentes (éventuellement archiver les enregistrements supprimés)
  • Envisagez de le faire automatiquement une fois par jour ou une fois par semaine.
• Reconstruire les index
• Reconstruire les tables (bcp data out/in)
• Vider/recharger la base de données (drastique, mais peut corriger la corruption)
• Créer un nouvel index plus approprié
• Exécutez DBCC pour voir s'il y a une corruption possible dans la base de données
• Verrouillages/Interblocages
  • Assurez-vous qu'aucun autre processus ne s'exécute dans la base de données
    • Surtout DBCC
  • Utilisez-vous le verrouillage au niveau de la ligne ou de la page ?
  • Verrouiller les tables en exclusivité avant de lancer la requête
  • Vérifier que tous les processus accèdent aux tables dans le même ordre
• Les index sont-ils utilisés de manière appropriée ?
  • Les jointures n'utiliseront l'index que si les deux expressions sont exactement du même type de données
  • L'index ne sera utilisé que si le ou les premiers champs de l'index correspondent à la requête
  • Les index clusterisés sont-ils utilisés le cas échéant ?
    • données de plage
    • Champ WHERE entre valeur1 et valeur2
• Les petites jointures sont de belles jointures
  • Par défaut, l'optimiseur ne prendra en compte que 4 tables à la fois.
  • Cela signifie que dans les jointures avec plus de 4 tables, il y a de bonnes chances de choisir un plan de requête non optimal
• Décomposer la jointure
  • Pouvez-vous rompre la jointure ?
  • Pré-sélectionner les clés étrangères dans une table temporaire
  • Faire la moitié de la jointure et placer les résultats dans une table temporaire
• Utilisez-vous le bon type de table temporaire ?
  • #temp les tables peuvent fonctionner bien mieux que @table variables avec de gros volumes (milliers de lignes).
• Maintenir les tableaux récapitulatifs
  • Construire avec des déclencheurs sur les tables sous-jacentes
  • Construire quotidiennement / toutes les heures / etc.
  • Construire ad hoc
  • Construire progressivement ou démonter/reconstruire
• Consultez le plan de requête avec SET SHOWPLAN ON
• Découvrez ce qui se passe réellement avec SET STATS IO ON
• Forcer un index en utilisant le pragma :(index :monindex)
• Forcer l'ordre des tables en utilisant SET FORCEPLAN ON
• Renifleur de paramètres :
  • Décomposer la procédure stockée en 2
  • appeler proc2 depuis proc1
  • permet à l'optimiseur de choisir l'index dans proc2 si @parameter a été modifié par proc1
• Pouvez-vous améliorer votre matériel ?
• À quelle heure courez-vous ? Y a-t-il un moment plus calme ?
• Replication Server (ou un autre processus non-stop) est-il en cours d'exécution ? Pouvez-vous le suspendre ? Exécutez-le par ex. horaire?