"Avertissements: l'opération a provoqué des E / S résiduelles" par rapport aux recherches clés
J'ai vu cet avertissement dans les plans d'exécution de SQL Server 2017:
Avertissements: l'opération a provoqué un résidu IO [sic]. Le nombre réel de lignes lues était de (3 321 318), mais le nombre de lignes renvoyées était de 40.
Voici un extrait de SQLSentry PlanExplorer:
Afin d'améliorer le code, j'ai ajouté un index non clusterisé, afin que SQL Server puisse accéder aux lignes pertinentes. Cela fonctionne bien, mais normalement il y aurait trop de (grandes) colonnes à inclure dans l'index. Cela ressemble à ceci:
Si j'ajoute uniquement l'index, sans inclure les colonnes, cela ressemble à ceci, si je force l'utilisation de l'index:
De toute évidence, SQL Server pense que la recherche de clé est beaucoup plus coûteuse que les E/S résiduelles. J'ai une configuration de test sans encore beaucoup de données de test, mais lorsque le code entre en production, il doit fonctionner avec beaucoup plus de données, donc je suis assez sûr qu'une sorte d'index NonClustered est nécessaire.
Les recherches de clés sont-elles vraiment si chères , lorsque vous exécutez sur des SSD, que je dois créer des index complets (avec beaucoup de colonnes d'inclusion)?
Plan d'exécution: https://www.brentozar.com/pastetheplan/?id=SJtiRte2X Il fait partie d'un long procédure stockée. Chercher IX_BatchNo_DeviceNo_CreatedUTC.
Le modèle de coût utilisé par l'optimiseur est exactement celui-ci: a modèle. Il produit généralement de bons résultats sur une large gamme de charges de travail, sur une large gamme de conceptions de bases de données, sur une large gamme de matériel.
Vous ne devez généralement pas supposer que les estimations de coûts individuelles seront fortement corrélées avec les performances d'exécution sur une configuration matérielle particulière. Le coût est de permettre à l'optimiseur de faire un choix éduqué entre les alternatives physiques candidates pour la même opération logique.
Lorsque vous entrez vraiment dans les détails, un professionnel qualifié de la base de données (avec le temps nécessaire pour régler une requête importante) peut souvent faire mieux. Dans cette mesure, vous pouvez considérer la sélection de plan de l'optimiseur comme un bon point de départ. Dans la plupart des cas, ce point de départ sera également le point d'arrivée, car la solution trouvée est assez bonne.
D'après mon expérience (et mon opinion), l'optimiseur de requêtes SQL Server coûte des recherches plus élevées que je ne le préférerais. Il s'agit en grande partie d'une gueule de bois du temps où les E/S physiques aléatoires étaient beaucoup plus chères par rapport à l'accès séquentiel que ce n'est souvent le cas aujourd'hui.
Pourtant, les recherches peuvent être coûteuses même sur les SSD, ou même lors de la lecture exclusivement à partir de la mémoire. Traverser des structures b-tree n'est pas gratuit. De toute évidence, le coût augmente à mesure que vous en faites plus.
Les colonnes incluses sont idéales pour les charges de travail lourdes en lecture OLTP, où le compromis entre l'utilisation de l'espace d'index et le coût de la mise à jour par rapport aux performances de lecture à l'exécution est logique. Il existe également un compromis à considérer autour de - stabilité du plan. Un indice couvrant complètement évite de se demander quand exactement le modèle de coût de l'optimiseur peut passer d'une alternative à l'autre.
Vous seul pouvez décider si les compromis en valent la peine dans votre cas. Testez les deux alternatives sur un échantillon de données représentatif et faites un choix éclairé.
Dans un commentaire de question, vous avez ajouté:
Êtes-vous en train de me dire que SQL Server ne connaît pas le coût des E/S résiduelles?
Non, l'optimiseur tient compte du coût des E/S résiduelles. En effet, en ce qui concerne l'optimiseur, les prédicats non SARGables sont évalués dans un filtre séparé. Ce filtre est poussé dans la recherche ou l'analyse en tant que résidu lors de la réécriture post-optimisation.