Pourquoi voudriez-vous mettre un index sur un point de vue?

Microsoft SQL Server vous permet d'ajouter un index à vue, mais pourquoi voudriez-vous faire cela?

Ma compréhension est que la vue est vraiment juste une sous-requête, c'est à dire, si je dis SÉLECTIONNEZ * à PARTIR de mavue, je suis vraiment en disant: SELECT * from (mavue de la Requête)

Il semble que les index sur les tables sous-jacentes seraient ceux qui ont le plus d'importance. Alors, pourquoi voudriez-vous un index séparé sur la vue?

InformationsquelleAutor Slider345 | 2011-01-19
  1. 35

    Si la vue est indexé puis des questions qui peuvent être résolues à l'aide de l'indice ne sera jamais besoin de consulter les tables sous-jacentes. Cela peut conduire à une énorme amélioration de la performance.

    Essentiellement, le moteur de base de données est maintenant un "résolu" version de la requête (ou, plutôt, l'indice de la requête) que vous mettez à jour les tables sous-jacentes, puis en utilisant résolu version plutôt que les tables d'origine lorsque cela est possible.

    Ici est un bon l'article dans le Journal de Base de données.

    • J'ai juste fait en essayant de l'expliquer à quelqu'un.
    • Il est un bon document sur l'indice des vues ici: msdn.microsoft.com/en-us/library/ms187864.aspx
    • +1: les Gens pensent que le non-vues matérialisées stocker les informations, mais c'est vraiment uniquement les vues matérialisées (où la prise en charge - c'est à dire: Pas de MySQL ou PostgreSQL) vue qui ne.
    • Merci, cela me donne une bien meilleure compréhension.
    InformationsquelleAutor Larry Lustig
  2. 4

    Microsoft SQL Server vous permet d'ajouter un index à vue, mais pourquoi voudriez-vous faire cela?

    Pour accélérer les requêtes.

    Ma compréhension est que la vue est vraiment juste une sous-requête, c'est à dire, si je dis SÉLECTIONNEZ * à PARTIR de mavue, je suis vraiment en disant: SELECT * from (mavue de la Requête)

    Pas toujours.

    Par la création d'un index cluster sur une vue, vous matérialiser le point de vue, et les mises à jour les tables sous-jacentes physiquement à jour la vue. Les requêtes à l'encontre de ce point de vue peut ou ne peut pas accéder aux tables sous-jacentes.

    Pas tous les points de vue peuvent être indexées.

    Par exemple, si vous utilisez GROUP BY en vue, pour qu'il soit indexable, il doit contenir un COUNT_BIG et toutes les fonctions d'agrégation dans il devrait le distribuer plus de UNION ALL (seulement SUM et COUNT_BIG sont en réalité). Ceci est nécessaire pour que l'indice soit maintenable et la mise à jour des tables sous-jacentes pourraient mettre à jour la vue en temps opportun.

    • Et vous ne pouvez pas l'indice d'un point de vue que les appels de vue.
    • oui et 2465 plus de restrictions à qui je n'ai pas mentionné ici.
    • J'ai pensé qu'il y avait plus que cela.
    • eh bien, peut-être 2466, mais je ne suis pas sûr.
    InformationsquelleAutor Quassnoi
  3. 3

    le lien suivant fournit mieux formulé des informations que je peux dire, en particulier dans la section des augmentations de rendement. Espérons que cela aide

    http://technet.microsoft.com/en-us/library/cc917715.aspx

    InformationsquelleAutor Daniel Casserly
  4. 0

    Vous créez un index sur une vue pour la même raison que sur une table de base: pour améliorer les performances des requêtes à l'encontre de ce point de vue. Une autre raison de le faire est de mettre en œuvre certaines contrainte d'unicité, vous ne pouvez pas mettre en œuvre à l'encontre des tables de base. SQL Server, malheureusement, ne permet pas de contraintes à être créé sur les points de vue.

    InformationsquelleAutor nvogel