Vous allez faire 3 types de réglages, 1 réactif et 2 proactif.
Réactif
À l'improviste, certaines requêtes commencent à vous poser des problèmes. Cela peut être dû à un bogue ou une fonctionnalité d'application, à une table dépassant les attentes, à un pic de trafic ou à l'optimiseur de requête devenant "créatif". Cela pourrait être une affaire de type `` oh-merde-le-site '' du milieu de la nuit, ou cela pourrait être en réponse à la lenteur du système de nature non critique. Quoi qu'il en soit, le caractère déterminant de l'accord réactif est que vous avez déjà un problème . Inutile de dire que vous voulez en faire le moins possible. Ce qui nous amène à ...
Proactif
Type 1: Maintenance de routine
Selon une sorte de calendrier, tous les quelques mois ou semaines, selon la fréquence à laquelle votre schéma change et la vitesse de croissance de vos données, vous devez examiner la sortie des outils d'analyse des performances de votre base de données (par exemple, les rapports AWR pour les DBA Oracle). Vous recherchez des problèmes naissants, c'est-à-dire des choses qui sont sur le point d'exiger un réglage réactif, ainsi que des fruits à faible pendaison, des articles qui ne risquent pas de causer des problèmes bientôt, mais qui peuvent s'améliorer avec peu d'effort dans l'espoir de prévenir loin -les problèmes futurs. Le temps que vous devriez y consacrer dépendra du temps dont vous disposez et de quoi d'autre vous pourriez le dépenser, mais le montant optimal n'est jamais nul. Cependant, vous pouvez facilement réduire le montant que vous devez dépenser en faisant plus de ...
Type 2: conception appropriée
L'avertissement de Knuth contre "l'optimisation prématurée" est largement connu et dûment respecté. Mais la bonne définition de «prématuré» doit être utilisée. Certains développeurs d'applications, lorsqu'ils sont autorisés à écrire leurs propres requêtes, ont tendance à adopter la toute première requête qu'ils rencontrent qui est logiquement correcte, et ne prêtent aucune attention aux performances, présentes ou futures. Ou ils peuvent tester par rapport à un ensemble de données de développement qui n'est tout simplement pas représentatif de l'environnement de production (astuce: ne faites pas cela! Les développeurs doivent toujours avoir accès à des données réalistes pour les tests.). Le fait est que le moment approprié pour régler une requête est quand elle est déployée pour la première fois, pas quand elle apparaît sur une liste de SQL peu performant, et certainement pas quand elle cause un problème critique.
Alors, qu'est-ce qui pourrait être considéré comme une optimisation prématurée du terrain DBA? Au sommet de ma liste serait de sacrifier la normalisation sans besoin démontré. Bien sûr, vous pouvez conserver une somme sur une ligne parent plutôt que de la calculer lors de l'exécution à partir des lignes enfants, mais en avez-vous vraiment besoin? Si vous êtes Twitter ou Amazon, la dénormalisation stratégique et le pré-calcul peuvent être vos meilleurs amis. Si vous concevez une petite base de données de comptabilité pour 5 utilisateurs, la bonne structure pour faciliter l'intégrité des données doit être une priorité absolue. D'autres optimisations prématurées sont également une question de priorité. Ne passez pas des heures à peaufiner une requête qui s'exécute une fois par jour et prend 10 secondes, même si vous pensez pouvoir la réduire à 0,1 seconde. Vous avez peut-être un rapport qui dure 6 heures par jour, mais explorez-le comme un travail par lots avant d'investir du temps dans le réglage. N'investissez pas dans une instance de rapport répliquée en temps réel distincte si votre charge de production ne dépasse jamais 10% (en supposant que vous puissiez gérer la sécurité).
En testant des données réalistes, en prenant des hypothèses éclairées sur les modèles de croissance et de trafic (plus les allocations pour les pics) et en appliquant vos connaissances sur les bizarreries de l'optimiseur de votre plate-forme, vous pouvez déployer des requêtes qui s'exécutent (presque) de manière optimale non seulement maintenant, mais à l'avenir et dans des conditions moins qu'idéales. Lorsque vous appliquez les techniques appropriées, les performances des requêtes peuvent être prédites avec précision et optimisées (dans le sens où chaque composant est aussi rapide qu'il doit l'être).
(Et pendant que vous y êtes, apprenez les statistiques! )