Indexer toutes les colonnes

Sachant qu'une colonne indexée conduit à une meilleure performance, est-il digne d'index de toutes les colonnes de toutes les tables de la base de données? Quels sont les avantages/inconvénients d'une telle approche?

Si il est digne, il est un moyen de créer automatiquement des index dans SQL Server? Mon application ajoute dynamiquement des tables et des colonnes (en fonction de la configuration de l'utilisateur) et je voudrais avoir leur auto indexés.

source d'informationauteur Moslem Ben Dhaou

  1. 14

    Il est difficile d'imaginer des scénarios du monde réel où l'indexation de chaque colonne serait utile, pour les raisons mentionnées ci-dessus. Le type de scénario nécessiterait un tas de requêtes différentes, tous les accès à exactement une colonne de la table. Chaque requête peut être l'accès à une autre colonne.

    Les autres réponses ne traitent pas les questions au cours de l' sélectionnez côté de la requête. De toute évidence, le maintien de l'index est un problème, mais si vous êtes à la création de la table/s une fois, puis la lecture de beaucoup, beaucoup de fois, la surcharge des mises à jour/insertions/suppressions n'est pas une considération.

    Un index contient les données d'origine, les points de dossiers/les pages où se trouvent les données. La structure d'un index, il est plus rapide de faire des choses comme: trouver une valeur unique, de récupérer les valeurs dans l'ordre, de compter le nombre de valeurs distinctes, et de trouver le minimum et le maximum des valeurs.

    Un index n'est pas seulement de prendre de l'espace sur le disque. Plus important encore, il s'occupe de la mémoire. Et, les conflits de mémoire est souvent le facteur qui détermine les performances de la requête. En général, la construction d'un index sur chaque colonne s'occupent plus d'espace que les données d'origine. (Une seule exception serait une colonne qui est relatif à l'échelle et a relativement peu de valeurs).

    En outre, pour satisfaire les nombreuses demandes que vous pourriez avoir besoin d'un ou plusieurs index plus les données d'origine. Votre cache de la page est assez rempli avec des données, qui peuvent augmenter le nombre de défauts de cache, qui engage des frais supplémentaires.

    Je me demande si votre question est vraiment un signe que vous n'avez pas modélisé vos structures de données de manière adéquate. Rares sont les cas où vous souhaitez que les utilisateurs à construire ad hoc des tables permanentes. Plus généralement, les données seraient stockées dans un format pré-défini, vous pouvez optimiser les conditions d'accès.

  2. 9

    Pas parce que vous avez à prendre en compte que chaque fois que vous ajoutez ou mettez à jour un enregistrement, vous devez recalculer votre index et d'avoir des indices sur toutes les colonnes prendrait beaucoup de temps et conduire à de mauvaises performances.

    Sorte de base de données, comme les données de l'entrepôt où il y a seulement les requêtes select est une bonne idée, mais sur la base normale, c'est une mauvaise idée.

    Aussi, ce n'est pas parce que vous êtes à l'aide d'une colonne dans une clause where vous devez ajouter un index sur elle.
    Essayez de trouver une colonne où le record de presque tous unique comme une clé primaire et que vous ne modifiez pas souvent.
    Une mauvaise idée serait de l'indice sur le sexe d'une personne, car il n'y a que 2 valeurs possibles et le résultat de l'index qu'à découper les données, puis il va chercher dans presque tous les dossiers.

  3. 2

    Non, il existe une surcharge dans le maintien de l'index, pour l'indexation de toutes les colonnes de ralentir l'ensemble de vos insérer, mettre à jour et supprimer des opérations. Vous ne devez indexer les colonnes que vous êtes souvent référencement dans les clauses where, et vous verrez un avantage.

  4. 2

    Indices de prendre de la place. Et qu'ils prennent le temps de créer, de reconstruction, de maintenir, etc. Donc il n'y a pas un rendement garanti sur les performances de l'indexation de n'importe quelle colonne. Vous ne devez indexer les colonnes qui donnent à la performance pour les opérations que vous allez utiliser. Index de l'aide de lectures, donc si vous êtes pour la plupart de la lecture, de l'indice des colonnes qui seront recherchés sur, triés par, ou liées à d'autres tables sur le plan relationnel. Sinon, c'est plus cher que ce que vous pouvez voir.

  5. 2

    Non, vous ne devriez pas l'indice de l'ensemble de vos colonnes, et il y a plusieurs raisons à cela:

    • Il y a un coût à l'entretien de chaque indice au cours d'une instruction insert, update ou delete, qui sera la cause de chacune de ces transactions à prendre plus de temps.
    • Il permettra d'augmenter l'espace de stockage nécessaire puisque chaque indice prend de la place sur le disque.
    • Si les valeurs de la colonne ne sont pas disperser, l'index ne sera pas utilisé/ignorés (ex: Un genre de drapeau).
    • Composite index (index avec plus d'une colonne) peut grandement bénéficier de la performance pour souvent where, GROUP BY, ORDER BY ou des clauses JOIN multiple et unique index ne peuvent pas être combinées.

    Vous êtes beaucoup mieux d'Expliquer à l'aide de plans et d'accès aux données et d'ajouter des index lorsque c'est nécessaire (et uniquement lorsque cela est nécessaire, à mon humble avis), plutôt que de les créer en toutes les.