J'ai créé un script pour trouver la sélectivité de chaque colonne pour toutes les tables. Dans certaines tables de moins de 100 lignes, la sélectivité d'une colonne est supérieure à 50%. Où Sélectivité = Valeurs distinctes/Nombre total de lignes. Ces colonnes sont-elles éligibles pour un index? Ou, pouvez-vous me dire l'exigence minimale pour le nombre de lignes pour créer un index?Quel est le nombre minimum de lignes requises pour créer un index?
Vous pouvez indexer sur une colonne - la question est de savoir si elle a un sens et si cet indice sera utilisé ....
En règle générale, une sélectivité de moins de 1-5% pourrait fonctionner - le plus petit ce pourcentage, le meilleur. Le meilleur est celui de valeurs uniques parmi une grande population, par ex. un seul identifiant client sur des centaines de milliers - ces indices seront certainement utilisés.
Des choses comme le genre (seulement 2 valeurs) ou d'autres choses qui n'ont qu'un nombre très limité de valeurs possibles ne fonctionnent généralement pas bien sur un index. Au moins de leur propre chef, ces colonnes pourraient être incluses dans un autre index en tant que deuxième ou troisième colonne.
Mais vraiment, la seule façon de savoir si oui ou non un indice logique est de
Il n'y a pas de règle d'or pour savoir quand un index sera utilisé (ou ignoré) - trop de variables jouent dans cette décision.
Pour des conseils d'experts sur la façon de traiter les indices, et comment savoir quels indices pourraient ne pas se habituer, et quand il est logique de créer un index, voir les messages du blog de Kimberly Tripp:
Je ne suis pas sûr de sql-server, mais la plupart des SGBD ne pas utiliser un index pour la récupération i f il peut récupérer toutes les lignes de la table dans une seule E/S. Vous verrez ceci sur les explications de PLAN, certaines tables sont toujours balayées par tablespace.
à mon humble avis, une table avec moins de 5000 lignes ne vaut pas pour l'analyse cardinalité si le SGBD est en cours d'exécution sur un serveur.
La plupart des SGBD utilisent un cache pour les données et le code (procédure stockée, plan d'exécution, etc.). Dans SQL Server je pense qu'il appelle les données et cache de procédure, et Oracle, il est appelé le cache tampon et la SGA. Les données de table et/ou l'index peuvent être dans le cache.
Les tables de petite taille fréquemment consultées se placeront probablement dans la mémoire cache. Mais la table peut être expulsée du cache, disons, si une requête charge de nouvelles données à partir du disque. Il existe des options pour indiquer que vous voulez qu'une table soit en permanence dans le cache (voir PINTABLE).C'est peut-être une meilleure stratégie que d'utiliser un index si votre table est très petite (ce qui est votre cas). Ajouter un index (qui serait toujours dans le cache) pourrait aider, mais je ne sais pas quel serait le gain.
La grande différence dans les performances est l'accès au disque par rapport à l'accès à la mémoire. Le but de l'index est de réduire la quantité de données à lire sur le disque, mais s'il est déjà en mémoire, le gain est probablement faible.
J'ai table avec 3 valeurs interger et tous sont dostinct. La sélectivité de cela est plus de 95%. Et cette table est principalement utilisée avec une instruction select uniquement. Alors est-ce physible de créer un index sur ça? – Paresh
95% de signification sélective? Typiquement, vous voulez une sélectivité très faible - vous voulez qu'une seule valeur (ID = 55) ne sélectionne qu'une quantité minimale de lignes. Si votre sélectivité dans ce scénario (pourcentage du nombre de lignes sur le total sera sélectionné pour une valeur donnée de votre champ) est inférieure à 5% ou même inférieure à 1%, il est donc logique d'indexer. –
"Choses comme le genre (seulement 2 valeurs)" maintenant que c'est 2018, cette partie de votre réponse est obsolète. Le genre devrait être VARCHAR (255) à partir de maintenant. Personnellement, je m'identifie comme un hélicoptère d'attaque apache. –