Y a-t-il un avantage à ne pas partitionner l'alignement d'un index?

9

J'ai le privilège de gérer une grande table OLAP partitionnée. En examinant ce tableau, j'ai remarqué que l'un des index n'est pas aligné avec le schéma de partitionnement. Étant donné que l'auteur n'est pas disponible et que les recherches Google soigneusement conçues n'ont donné aucun résultat utile, je ne sais pas si c'était intentionnel ou accidentel.

Y a-t-il une raison pour ne pas partitionner l'alignement d'un index sur SQL Server 2008?

— Robin
source

1

Peut-être. Recherchez votre utilisation des statistiques d'index pour voir si cet index est utilisé. Si tel est le cas, utilisez des événements étendus ou une trace côté serveur pour capturer les requêtes qui atteignent cet index. S'ils fonctionnaient mieux sur un index aligné sur une partition, tant mieux. Sinon, vérifiez s'ils ont réellement besoin d'index partitionnés non alignés. S'ils ne le font pas, je dirais de toute façon que la partition soit alignée, car les futures requêtes pourront en tirer parti. Bien sûr, si le coût / l'effort / la panne est trop élevé, ne le faites pas.

— Ali Razeghi

D'après ce que j'ai lu, la meilleure pratique pour indexer une table partitionnée consiste à aligner l'index avec le schéma de partitionnement. Cette table particulière m'a fait penser que je veux comprendre un cas d'utilisation pour ne pas aligner un index avec le schéma de partition. Je n'essaie pas de résoudre un problème spécifique, je n'ai donc pas de requête à analyser.

— Robin

Une autre raison de concevoir un index non aligné est un index unique (y compris la clé primaire ou la contrainte unique) qui n'inclut pas la colonne de partitionnement. Dans ce cas, l'index ne doit pas du tout être partitionné ou partitionné à l'aide d'une fonction / d'un schéma différent.

— Dan Guzman

11

Le principal avantage de ne pas diviser un index (non unique) sur un objet de base partitionné est que cela fonctionne autour d' une limitation de l' optimiseur de requêtes de longue date liées aux demandes de données ordonnées telles que MIN, MAXou TOP (n)requêtes.

Sur un index partitionné, l'optimiseur ne peut généralement pas traduire MIN, MAXou TOP (n)vers la même opération par partition , suivi d'un agrégat global final sur les agrégats partiels par partition. L'optimiseur choisit plutôt un plan d'exécution qui analyse toutes les partitions de l'index. L'exception à cela est le cas unique où l'opération d'agrégation ou de sommet est spécifiée sur la colonne de partitionnement.

Je dois mentionner qu'il existe également de très bonnes raisons de ne pas avoir d'index non alignés. Le choix d'utiliser un index non aligné devrait être un choix très éclairé. Je l'ai fait moi-même (rarement) dans le passé, mais dans des circonstances très spécifiques où les avantages l'emportaient clairement sur les coûts, ou il n'y avait pas d'autre alternative raisonnable.

Article d'Itzik Ben-Gan expliquant le problème.

— Paul White 9
source

3

Il existe un problème évident concernant certaines contraintes (par exemple, uniques) nécessitant un index non aligné.

Autre que les indices non alignés ont un grand coût (surtout ils éviter de nombreux opérateurs parallèles d'aller thread par partition et les alternatives sont coûteuses mémoire) et donc je vous conseille vivement contre de tels indices. Même avec les cas énumérés par Paul, je déconseillerais toujours les index non alignés.

— Remus Rusanu
source

1

Oui. Le choix d'un indice non aligné devrait être un choix très éclairé. Je l'ai fait moi-même (rarement) dans le passé, mais dans des circonstances très spécifiques où les avantages l'emportaient sur les coûts.

— Paul White 9

2

Les index non alignés annulent le principal avantage du partitionnement qui consiste à changer de partition. Si vous ne dépendez pas de cela et que vous partitionnez pour d'autres raisons (stockage différent, partitions en lecture seule, statistiques incrémentielles, ...) alors allez-y et créez indexex non aligné.

Les index non alignés sont utiles car vous pouvez appliquer des contraintes uniques à l'ensemble de la table avec eux. De plus, les index non alignés ne nécessitent pas que la clé de partitionnement soit un préfixe de recherche implicite. Imaginez avoir 10000 partitions et des requêtes non basées sur la clé de partitionnement. Le plan d'exécution devra alors rechercher dans 10000 partitions si l'index était aligné. Les autres réponses ont d'autres exemples.

— usr
source