Je propose une base de données JET à SQL Server Express 2008 R2 et avant de le faire, je réévaluise le schéma (il a été conçu en 1997-1998 et le gars qui l'a conçu (c'est-à-dire moi) était quelque chose d'un moron!).
Ma question concerne les tables de jointure N: n avec une clé composite à deux colonnes. Dans Jet, des jointures sur la première colonne d'une touche composite à deux colonnes utiliseront l'index composite, mais les jointures de la deuxième colonne ne seront pas, donc en général, dans des bases de données à jet avec de grandes tables de jointure avec un nombre raisonnablement élevé d'enregistrements. , En plus de l'indice composite, j'ajoute un deuxième indice non unique sur la deuxième colonne.
Est-ce une bonne idée dans SQL Server?
(Peut-être que ce n'est pas une bonne idée dans Jet?)
3 Réponses :
Les mêmes règles s'appliquent dans SQL Server. Si vous avez un index sur (Columna, ColoxB) une requête sur uniquement la colonne ou la colonne et la colonne de colonne peut utiliser l'index, mais une requête sur seulement colonne ne peut pas. S'il est nécessaire de rejoindre Just ColdoB, vous devez absolument créer l'index.
Tout inconvénient, autre que les problèmes d'entretien d'index évidents?
Considérations sur l'espace pour stocker l'index. Surcharge supplémentaire sur les opérations d'insertion / mise à jour / Supprimer. Considérez également la cardinalité du colonne. Si c'est une cardinalité faible (peu de valeurs uniques), l'index peut ne pas aider autant.
En général, ma colonne colonne a une cardinalité inférieure à la colonne. L'annulerait et ajouterait l'index non-dupliqué sur la colonne avec la cardinalité supérieure être plus efficace?
Si B a une cardinalité inférieure, votre index d'origine (Columna, colonne) est dans le bon ordre. Il vous suffit de décider si un indice indépendant sur (colonne) serait bénéfique dans votre situation spécifique.
J'accepte cela comme la réponse, même si les autres réponses étaient aussi utiles. Ils étaient juste moins directs et ont incité beaucoup d'autres pensées.
Si vous avez un index composite sur les colonnes La réponse est donc que vous avez besoin d'index séparés sur (A, B) NO recherche, la numérisation de plage, le tri ou l'exploitation d'agrégats peut l'utiliser pour des expressions contenant uniquement B . Ceci est vrai pour SQL Server, comme il était vrai pour les pilotes JET (Rouge) (et je pense que pour Skip Scan opération.
(b) seul.
Si la table est principalement utilisée avec des jointures sur les deux colonnes, l'aidera-t-elle à sélectionner autant que dans un choix à l'aide de la 2e colonne d'une jointure? Ma pensée est que l'optimiseur va sélectionner d'abord sur le côté doté d'un index, puis a moins à faire de l'autre côté, donc avec les deux jointures, il va être plus efficace qu'avec la jointure uniquement du côté non annexé. Puisque je n'utilise presque jamais des tables de jointure sans les deux jointes, peut-être que cela ne va pas aider beaucoup?
Si la jointure est sur les deux colonnes, l'index sur (b) seul sera probablement ignoré. Mais si vous recherchez / rejoindre principalement sur a et b , parfois sur b seul jamais jamais jamais jamais < / i> sur A seul, vous pouvez envisager de changer l'index pour être sur (b, a) à la place.
En règle générale, l'ordre de colonne dans un index devrait être dans l'ordre croissant de sélectivité, à moins que ce soit spécifique par doit être adressé. Mettre des colonnes à bas sélectivité sur le côté le plus à gauche permet aux requêtes d'agrégat et de grande gamme pour toujours utiliser l'index, mais vous avertiez qu'une colonne de sélectivité faible tombera rapidement dans le piège à pointe: sqlskills.com/blogs/kimberly/category/the-tipping-point.aspx . Avoir une colonne de sélectivité faible (comme type ) sur le plus à gauche fait le plus de sens sur les index en cluster, car les index en cluster sont toujours couvrant, n'ont pas de point de basculement.
Lorsque je dis «Inscrivez-vous sur les deux colonnes», je veux dire en fonctionnement en tant que table de jointure N: N, avec Columna jointe à Tablea et à ColoMB a rejoint la tableb. Je n'utilise jamais des touches composites de table multicolores de jointure en tant que FK dans une autre table, je n'ai donc jamais rejoint la colonne + colonne à tablier.
Il n'y a jamais de commande sur ces clés composites - elles sont n: n des tables de jointure et la commande n'a aucune signification (les colonnes sont des valeurs FK dans les touches de substitution automatique des tables jointes).
Si vous avez une table étroite qui agit comme une jointure N: N (n'a que deux colonnes, l'une est FK sur A et une est FK ON B) alors je recommanderais d'avoir deux index, un sur (A, B ) et un sur (b, a) (l'un des index sera l'index en clustere). Avoir juste un index sur B seul ne sera pas un index de couverture. Avoir un index sur (b) inclure (a) ne justifie probablement pas les économies par rapport à la perte d'ordre secondaire sur A (peut être levé par des requêtes agrégées et de nombreux plus voire avec une commande par ).
Désolé, ma familiarité avec des termes si pointté - que voulez-vous dire "Index on (B) inclure (A)"? Deux index composites me semblent avoir aucun sens, car je n'utilise jamais même l'indice composite d'origine pour une jointure, sauf dans la mesure où il est utilisé pour des jointures à l'aide de Columna. Comme je l'ai dit, la clé composite n'est pas stockée comme FK dans aucune table, donc je ne vois donc pas quel avantage il pourrait y avoir deux clés composites. Je suppose qu'une fois que je fais la hausse (je couronne SSMA pour voir ce que les avertissements apparaissent), je devrais tester comme @luka suggère.
Inclure : voir msdn.microsoft.com/fr- US / Bibliothèque / MS190806.aspx . Lorsque la table n: n est recherchée, la requête aura toujours besoin de A et B . Un index secondaire sur B seul provoquera la requête ne pas avoir la valeur requise une valeur et devra faire une recherche par signet dans l'index en cluster. C'est pourquoi un inclure (a) est nécessaire. Mais le même effet peut être obtenu en ayant l'index sur (b, a) , au coût d'ajout du stockage A à toutes les pages non-feuillettes, mais ceci est L'emporte-vous probable au profit d'avoir A commandé dans l'index secondaire.
@Remus, si l'index en clustered est sur (A, B) , n'aurait-il pas un index non clusterné sur (b) seul est nécessairement un indice de couverture, en vertu de la vertu de la clé de clustering? Deuxième question: Les touches de regroupement sont-elles au niveau de la feuille d'un indice non groupé équivalent à (b) comprennent (a) ou (b, a) ? J'ai toujours supposé le premier.
@Peter: Vous êtes correct, toutes les touches manquantes (et uniquifier, le cas échéant) à partir de l'indice en clustere sont toujours ajoutées "cachées" aux nœuds de feuilles dans un indice non en cluster, de sorte que l'entrée dans le NC puisse être adaptée à l'entrée en cluster. Mais je préfère toujours TOT Ajoutez les touches requises par les requêtes pour devenir explicitement des index comme inclure ou comme des clés secondaires dans la définition non clustée: cela rend les choses plus claires et visibles, et cela ne tourne pas L'indice en une non-revêtement si la définition clé en cluster change au fil du temps.
Je suis enlevé cela parce que j'aimerais accepter deux réponses, mais je ne peux pas.
Pour vous aider davantage, juste un conseil, dans SQL Server à l'aide du studio de gestion, vous pouvez évaluer les performances en "Afficher le plan d'exécution estimée". Il montra comment les index et la jointure fonctionne.
Vous pouvez également utiliser le DTA (conseiller de syntonisation du moteur de base de données) pour plus d'informations et d'optimisation.