Les optimiseurs de requête de base de données sont-ils conscients des différences de performances de stockage?

Si je comprends bien, l'optimiseur de requêtes dans SQL Server (ou tout autre SGBDR, vraiment) n'est pas au courant des performances du stockage sous la base de données et prendra des décisions comme si tout le stockage avait un coût égal. Est-ce exact ou existe-t-il une connaissance des performances de stockage prise en compte?

Dans un exemple totalement artificiel, disons que mes lignes de table sont stockées sur un disque SSD dans mon SAN avec des temps d'accès instantanés, où mes index sont stockés sur des disques SAS qui sont extrêmement surchargés, ce qui entraîne une saturation du disque et des files d'attente de disque constantes. Lorsque le SGBDR génère le plan d'exécution, est-il plus susceptible de favoriser une analyse de table qu'une opération d'index (ou éventuellement un index skinny et des recherches de table associées, par opposition à un index de couverture, car c'est moins d'E / S sur les disques SAS)?

Je soupçonne que la réponse est solide: "il n'y a aucune chance que l'optimiseur soit intelligent ou même conscient des performances du disque", mais je voulais juste voir si quelqu'un le savait avec certitude. J'utilise SQL Server, mais je suis intéressé par tout système de base de données.

L'optimiseur de requêtes du serveur SQL ne prend pas en compte les variations des performances du disque lors de la compilation d'un plan de requête. Paul White fournit un excellent aperçu de l'optimiseur basé sur les coûts de Sql Server ici:

https://sqlkiwi.blogspot.com/2010/09/inside-the-optimizer-plan-costing.html

Quelques points clés:

• L'optimiseur n'essaie pas de calculer le coût exact d'un plan. Il essaie de choisir le plan avec le coût le plus bas relatif entre plusieurs alternatives.

• C'est une vision simplifiée de la réalité. Il suppose qu'un serveur peut effectuer 320 io / sec et que les performances du processeur n'ont pas augmenté depuis plus d'une décennie.

• Même si les serveurs ont aujourd'hui des caractéristiques de performances très différentes, l'optimiseur fait toujours un très bon travail dans la majorité des cas.

Alors, pourquoi Microsoft n'ajoute-t-il pas une intelligence supplémentaire à l'optimiseur? À l'avenir, cependant, il est plus probable que de petits ajustements soient apportés aux coûts des itérateurs individuels. Actuellement, l'avantage n'est pas là pour justifier l'effort.

Vous pouvez utiliser des appels dbcc non documentés pour modifier certaines des hypothèses des optimiseurs de requête. NE PAS LES UTILISER SUR UN SERVEUR DE PRODUCTION

DBCC SETIOWEIGHT(<multiplier>)
DBCC SETCPUWEIGHT(<multiplier>)

Les deux ont des valeurs par défaut de 1. Jouez avec eux et voyez si vous pouvez trouver des valeurs différentes qui produisent systématiquement de meilleurs plans dans la majorité des cas. Vous constaterez que de petits changements ne changeront pas la majorité des plans et que des changements importants généreront des plans vraiment bizarres.

Un point supplémentaire est que même si SQL ne prend pas en compte les performances io lors de la compilation d'un plan, il répond aux performances io lors de l'exécution du plan (limitation des lectures anticipées si io est saturé, etc.)

L'optimiseur de requêtes Db2 pour LUW connaît les caractéristiques de performances matérielles de la machine sur laquelle il s'exécute et les prend en considération.

Plus précisément, chaque espace overheaddisque logique possède deux paramètres numériques qui reflètent les performances de stockage sous-jacentes:, qui reflètent la surcharge du contrôleur d'E / S et la recherche de disque et le temps de latence en millisecondes, et transferrate, qui indique le temps requis pour transférer une page d'espace disque logique du disque vers la mémoire.

Ces paramètres peuvent être spécifiés au moment de la création de l'espace disque logique pour remplacer les valeurs par défaut dérivées heuristiquement.

Les paramètres de performances d'E / S, ainsi que le cpu_speedparamètre de niveau gestionnaire de base de données, sont utilisés par l'optimiseur pour calculer les coûts d'E / S et de CPU de chaque opérateur de plan de requête et affecteront donc le plan finalement choisi. Par la suite, votre scénario serait complètement plausible en Db2. De même, sur un système avec une vitesse de processeur très élevée et des performances de disque médiocres, l'optimiseur peut préférer les opérateurs gourmands en processeur (par exemple, l'analyse de table plus le tri) à ceux plus gourmands en E / S (par exemple, l'accès aux tables indexées).

Je pense que Db2 for z / OS tient également compte des caractéristiques de performances matérielles sous-jacentes, en les obtenant de la couche de gestion du stockage, et non dans le cadre de la configuration de la base de données.