Quand est-il préférable de créer des STATISTIQUES au lieu de créer un index?
J'ai trouvé de nombreuses informations sur ce que STATISTICS sont: comment elles sont gérées, comment elles peuvent être créées manuellement ou automatiquement à partir de requêtes ou index, etc. Mais, je n'ai pas pu trouver de conseils ou d'informations sur les "meilleures pratiques" concernant quand pour les créer: quelles situations bénéficient plus d'un objet STATISTIQUES créé manuellement que d'un index. J'ai vu des statistiques filtrées créées manuellement aider les requêtes sur les tables partitionnées (parce que les statistiques créées pour les index couvrent la table entière et ne sont pas par partition - génial!), Mais il doit sûrement y avoir d'autres scénarios qui bénéficieraient d'un objet de statistiques tout en ne pas avoir besoin du détail d'un index, ni valoir le coût de maintenir l'index ou d'augmenter les chances de blocage/dead-locks.
@JonathanFite, dans un commentaire, a mentionné une distinction entre les index et les statistiques:
Les index aideront SQL à trouver les données plus rapidement en créant des recherches triées différemment de la table elle-même. Les statistiques aident SQL à déterminer la quantité de mémoire/d'effort qui sera nécessaire pour satisfaire la requête.
C'est une excellente information, principalement parce qu'elle m'aide à clarifier ma question:
Comment savoir cela (ou toute autre information technique sur les quoi et comment s liés aux comportements et à la nature de STATISTICS) aident à déterminer quand choisir CREATE STATISTICS plus de CREATE INDEX, en particulier lorsque la création d'un index créera l'objet STATISTICS associé? Quel scénario serait mieux servi en ayant uniquement les informations STATISTIQUES et pas avoir l'indice?
Il serait extrêmement utile, si possible, d'avoir un exemple de scénario de travail où l'objet STATISTICS est mieux adapté qu'un INDEX.
Étant donné que je suis un apprenant/penseur visuel, j'ai pensé qu'il pourrait être utile de voir les différences entre STATISTICS et INDEXes, côte à côte, comme un moyen possible d'aider à déterminer quand STATISTICS sont le meilleur choix.
Thingy PROs CONs
------- ---------- -------------------
INDEX * Can help sorts. * Takes up space.
* Contains data (can * Needs to be maintained (extra I/O).
"cover" a query). * More chances for blocking / dead-locks.
STATISTICS * Takes up very little space. * Cannot help sorts.
* Lighter maintenance / won't * Cannot "cover" queries.
slow down DML operations.
* Does not increase chances
of blocking / dead-locks.
Voici quelques ressources que j'ai trouvées en cherchant ceci, une qui pose même cette même question, mais sans réponse:
Index SQL Server vs statistique
Questions statistiques SQL Server que nous étions trop timides à poser
Statistiques. Les histogrammes multicolonnes sont-ils possibles?
** Pour être clair, je n'ai pas de réponse à cela et je cherche en fait à obtenir des commentaires de quelques personnes, espérons-le, pour fournir ce qui semble étrangement manquer des informations ici dans les interwebs.
Votre question tourne autour - Quand est-ce une bonne chose de simplement créer des statistiques vs créer un index (qui crée des statistiques).
D'après mes notes internes sur le serveur SQL (classe SQLSkills - IE1 et IE2) et livre sur les internes SQL Server , voici ma limitée compréhension:
Les statistiques SQL Server ne sont rien d'autre que des objets système qui contiennent des informations essentielles sur les valeurs de clé d'index et les valeurs de colonne normales.
SQL Server utilise un modèle basé sur les coûts pour choisir le plus rapidement possible un plan d'exécution "suffisamment bon". L'estimation de la cardanilité (estimation du nombre de lignes à traiter à chaque étape de l'exécution de la requête) est le facteur le plus important dans l'optimisation des requêtes qui affecte la stratégie de jointure, l'exigence d'allocation de mémoire, la sélection du thread de travail ainsi que le choix des index lors de l'accès aux données .
SQL Server n'utilisera pas d'index non cluster lorsqu'il estime qu'un grand non. des opérations de bouclage KEY ou RID seront nécessaires, donc il maintient des statistiques sur les index (et sur les colonnes) qui aideront dans de telles estimations.
Il y a 2 choses importantes à propos des statistiques:
L'histogramme stocke UNIQUEMENT des informations sur la distribution des données pour la colonne de statistiques (index) la plus à gauche. Il stocke également des informations sur la densité multi-colonnes des valeurs clés. Donc, essentiellement, l'histogramme stocke la distribution des données pour la colonne de statistiques la plus à gauche uniquement.
SQL Server conservera au plus 200 étapes dans l'histogramme quelle que soit la taille de la table. Les intervalles couverts par chaque étape de l'histogramme augmentent à mesure que la table grandit, ce qui conduit à des statistiques "moins précises" pour les grandes tables.
N'oubliez pas que la sélectivité d'indice est une métrique qui est inversement proportionnelle à la densité, c'est-à-dire que plus une colonne a de valeurs uniques, plus sa sélectivité est élevée.
Lorsque des requêtes particulières ne s'exécutent pas très souvent, vous pouvez choisir de créer des statistiques au niveau des colonnes plutôt qu'un index. Les statistiques au niveau des colonnes aident Query Optimizer à trouver de meilleurs plans d'exécution, même si ces plans d'exécution ne sont pas optimaux en raison des analyses d'index impliquées. Dans le même temps, les statistiques n'ajoutent pas de surcharge lors des opérations de modification des données et permettent d'éviter la maintenance des index. Cette approche ne fonctionne que pour les requêtes rarement exécutées.
Référer :
- Les statistiques de colonne donnent un avantage à l'optimiseur par Kalen Delaney
- Statistiques, mensonges damnés et statistiques - Qu'est-ce que Statman? par Conor Cunningham
Remarque: Quelqu'un comme Paul White ou Aaron Bertrand peut sonner pour donner plus de couleur à votre bonne question . =
Je dirais que vous avez besoin d'un index lorsque vous devez pouvoir limiter la quantité de données/accéder rapidement aux données correctes en fonction du ou des champs.
Vous avez besoin de statistiques lorsque vous avez besoin de l'optimiseur pour comprendre la nature des données afin de pouvoir effectuer les opérations de la meilleure façon possible.
Ce que j'ai compris, les statistiques filtrées aident lorsque vous avez des asymétries dans vos données qui affectent fortement le plan, par exemple en cas de débordement de pile, peu d'utilisateurs ont un grand nombre de publications, donc utiliser uniquement des publications moyennes par utilisateur n'est pas vraiment la meilleure estimation. Vous pouvez donc créer des statistiques filtrées sur userId en fonction du nom d'utilisateur, puis SQL Server doit savoir que lorsque ce nom d'utilisateur est dans la requête, il s'agit de l'ID utilisateur qu'il obtiendra, et il devrait être en mesure de comprendre que le le champ indexé dans la table des publications aura une énorme quantité de lignes avec cet identifiant car l'histogramme existe là. Avec des moyennes, ce n'est pas possible.
De 70 à 461 Livre d'entraînement d'Itzik Ben-Gan
Il n'y a que quelques raisons possibles pour créer des statistiques manuellement. Par exemple, lorsqu'un prédicat de requête contient plusieurs colonnes qui ont des relations entre colonnes; les statistiques sur les multiples colonnes peuvent aider à améliorer le plan de requête. Les statistiques sur plusieurs colonnes contiennent des densités inter-colonnes qui ne sont pas disponibles dans les statistiques à colonne unique. Toutefois, si les colonnes sont déjà dans le même index, l'objet de statistiques multicolonnes existe déjà, vous ne devez donc pas en créer un autre manuellement.