Ce qui est mieux: Bookmark/Clé de Recherche ou d'Analyse d'Index

Je sais qu'un index chercher est mieux qu'un index analyse, mais ce qui est préférable dans SQL Server expliquer plans: Index de recherche ou de Clé de Recherche (Signet dans SQL Server 2000)?

S'il vous plaît dites-moi qu'ils n'ont pas changer le nom nouveau pour SQL Server 2008...

  • le contenu de la question demande une chose et le titre d'une autre chose....
InformationsquelleAutor OMG Ponies | 2009-09-08
  1. 48

    De recherche d'Index, à chaque fois.

    Recherches sont chers, si ce n'est la couverture des index et surtout les INCLURE la clause a été ajoutée pour les rendre meilleures.

    Dire que si vous vous attendez à ce qu'une seule ligne, par exemple, une recherche suivie d'une recherche peut être mieux que d'essayer de couvrir une requête. Nous comptons sur ce pour éviter encore un autre indice dans certaines situations.

    Edit: Simple de parler de l'article: À l'aide de la couverture des Index pour Améliorer les Performances des Requêtes

    Édition, Août 2012

    Recherches arriver par ligne qui est pourquoi ils l'échelle de mal. Finalement, l'optimiseur va choisir une analyse d'index cluster au lieu de chercher+recherche parce que c'est plus efficace que de nombreuses recherches.

    • +1 pour le revêtement des indices et de la Simple-Talk lien (excellent stuff)
    InformationsquelleAutor gbn
  2. 9

    Clé de recherche est très similaire à une recherche d'index cluster (avant 2005 SP2 a été nommé "chercher avec la recherche"). Je pense que la seule différence est que la Clé de Recherche peut indiquer l'un des PRE-FETCH argument de mandater le moteur d'exécution pour extraire plus de touches dans le cluster (ie. faire une recherche d'index cluster suivie par scan).

    Voir une Clé de Recherche ne doit pas vous effrayer. C'est la normale opérateur utilisé dans les Boucles Imbriquées, et les Boucles Imbriquées est run-of-the-mill opérateur de jointure. Si vous voulez améliorer un plan, essayez de l'améliorer sur la jointure et voir si elle peut utiliser une jointure de fusion à la place (c'est à dire. les deux côtés de la jointure peut fournir des lignes sur la même touche de commande, le plus rapide de rejoindre) ou un hash join (avoir suffisamment de mémoire pour la QO à envisager une jointure de hachage, ou de réduire la cardinalité par le filtrage des lignes avant de les rejoindre plutôt qu'après).

    • êtes-vous sûr... une clé de recherche est une recherche de signet = cher, non?
    • autant que je sache est exactement aussi cher qu'une recherche, il se traduit par la même opération physique. Le présence de look-ups bien indiquer potentiel problèmes comme slonon-la couverture des index. Notez qu'avec joint une recherche peut de mieux que de chercher parce que les recherches peuvent spécifier la pré-extraction.
    • slonon-convering indexes => slow joins or non-covering indexes (faute de frappe)
    • btw bien sûr qu'un seek + une recherche est plus cher que de simplement chercher, donc si vous pouvez convertir réduire le chercher+recherche à un seul seek (ie. index de couverture) par tous les moyens, oui, c'est mieux. Mon point est que c'est pas le look qui est le coûteux comparativement à une recherche, mais pourquoi est le QO choisir d'utiliser une recherche (ie. les besoins à couvrir la projection des colonnes)
    • Assez juste, je comprends ce que vous dites. Toutefois, si jamais vous voyez un singleton clé de recherche? Ou est toujours liée à une autre recherche/balayage? Aussi, si la première recherche/balayage donne un 1000 lignes, il est probable que vous avez un tri intermédiaires ou 1000 discret non contigus recherches
    • Je pense que les recherches sont toujours en suivant quelques autres accès opération qui se nourrit de la recherche du RID ou de la clé à rechercher. Si la clé de venir un coup d'oeil à partir de la requête arguments, la recherche serait toujours un chercher autant que je sache.
    • Pour summ, si vous modifiez un plan en quelque sorte qu'il remplace une recherche avec celui de chercher, rien n'est gagné réellement. La vraie solution est d'en éliminer la cause, de la recherche et d'élaborer un plan qui, par exemple, a un seul chercher là où, auparavant, aurait recours à chercher et une recherche.
    • Donc, nous sommes d'accord que les recherches sont mauvais alors...? 🙂
    • Couverture de couverture de déclarations sont toujours dangereux 🙂 mais oui, les recherches sont un signe de problèmes.
    • Je les ai trouvés pour être tout à coup introduire dans certaines situations, lorsqu'un HAUT énoncé est ajouté, provoquant une requête qui, normalement, a pris moins d'une seconde à monter en flèche à environ 100 secondes, surtout quand il y a moins de lignes que le HAUT de déclaration demandé.

    InformationsquelleAutor Remus Rusanu
  3. 2

    Cette SORTE de question mentionne que les principales recherches sont quelque chose à éviter. Un index de recherche va certainement être la meilleure exécution de l'opération.

    InformationsquelleAutor Dustin Venegas