La plupart d'entre nous conviendront probablement que l'utilisation d'index de base de données est une bonne chose. Trop d'index et de performances peuvent en fait être dégradés.
En règle générale, quels champs doivent être indexés?
Quels champs ne doivent pas être indexés?
Quelles sont les règles d'utilisation des index tout en trouvant un équilibre entre trop d'index et pas assez d'index pour réaliser des améliorations de performances, pas de dégradation?
Réponses:
Court
La règle "trop d'index" est un peu trompeuse je pense.
Longue
Étant donné que la base de données moyenne est d'environ 98% des lectures (ou plus), les lectures doivent être optimisées. Un INSERT est une lecture s'il existe un index unique, par exemple. Ou le WHERE sur une mise à jour. J'ai lu une fois que même une base de données intensive en écriture est encore 85% de lectures.
Ce que vous avez, c'est une indexation de mauvaise qualité. Exemples:
cold, coleetcold, cole, colf)Notez qu'il est assez courant d'avoir des index plusieurs fois plus grands que vos données réelles, même dans les systèmes OLTP.
En général, je commencerais par
Ensuite, je regarderais:
Cela dit, j'ai enfreint ces règles pour certains systèmes après avoir vu comment les choses se déroulaient (10 milliards de lignes plus tard) pour régler un système. Mais je n'envisagerais jamais de ne pas indexer à moins que je puisse démontrer pourquoi je le fais.
la source
Vous devez profiler l'utilisation et la charge de votre base de données et identifier les goulots d'étranglement dus à des index manquants - ou à un trop grand nombre d'index. Ensuite, vous devez choisir l'index approprié - et cela nécessite une bonne connaissance des techniques d'indexation de base de données spécifiques.
la source
Tout simplement l'une des meilleures séries d'articles écrits sur les index à choisir et pourquoi serait par Gail Shaw. Vous pouvez retrouver les articles en cliquant ici
La question que vous posez peut recevoir une réponse de 50 manières différentes. Tout se résume vraiment aux données dont vous disposez et à la façon dont elles seront interrogées. Une règle générale est que vous devez toujours avoir un index cluster sur chaque table pour éviter les tas. Les index clusterisés doivent généralement être aussi petits que possible. Si la table a un index clusterisé, tous les enregistrements d'index sur les pages feuilles de l'index non clusterisé stockent la valeur d'enregistrement de l'index cluster respectif pour les recherches de signets. Si une table est un tas, SQL créera un identifiant unique pour les recherches de signets. Je ne me souviens pas de la taille, c'est 8 ou 16 octets. Cela pourrait finir par être un type de données beaucoup plus grand, puis dire un INT. Imaginez avoir 8 index non cluster sur une table de tas.
la source
Je veux ajouter ici que différentes bases de données nécessitent des stratégies différentes. Comparons MySQL avec InnoDB et PostgreSQL par exemple.
InnoDB
Les tables InnoDB sont essentiellement un index b-tree de la clé primaire qui est étendu pour inclure les informations de ligne dans l'entrée d'index. Les analyses d'ordre physique ne sont pas prises en charge et toutes les analyses se déroulent dans un ordre logique. Cela signifie deux choses:
Un balayage séquentiel dans Innodb génère beaucoup d' E / S de disque aléatoires , et
L'index de clé primaire doit être parcouru, que l'on utilise ou non un index secondaire.
Les recherches de clé primaire sont plus rapides dans ce modèle que dans toute autre approche.
Dans ce cas, il est très important d'indexer suffisamment de champs dans les tables de plusieurs pages. La règle typique est d'indexer tout ce que vous souhaitez filtrer.
PostgreSQL
PostgreSQL utilise des fichiers tas, une table par fichier (certaines tables peuvent contenir plusieurs fichiers) où les tuples sont alloués à partir de l'espace libre de ce tas. Les analyses d'ordre physique sont prises en charge. Pour qu'une analyse de l'ordre logique fonctionne, un index doit être ajouté.
Les clés primaires de PostgreSQL sont essentiellement un sous-ensemble d'index uniques où aucune valeur ne peut être NULL. Les contraintes UNIQUES sont effectuées à l'aide d'index implicites, et plusieurs autres types d'index sont pris en charge avec différentes opérations possibles dans l'index.
Ça signifie:
Recherches de clé primaire, en supposant qu'une table relativement grande nécessite de frapper un fichier d'index et un fichier de table. C'est beaucoup plus lent que l'approche de MySQL où l'index doit uniquement être parcouru et la ligne est contenue dans l'index.
Les analyses d'ordre physique fonctionnent beaucoup mieux, réduisant les E / S de disque aléatoires où un nombre important de lignes doivent être traitées.
Les analyses d'index secondaire fonctionnent mieux que celles de MySQL car un seul index doit être parcouru pour accéder à la partie physique de la table.
Dans ce modèle, les index sont souvent nécessaires mais le planificateur a plus de liberté pour utiliser un index, et les implications de ne pas en utiliser un sont souvent moins graves. Les tables sont plus généralement optimisées (plutôt que de se spécialiser dans les recherches pkey) et donc moins d'index sont nécessaires.
TL; DR
Apprenez à connaître votre SGBDR.
la source
Dans le manuel Oracle 11.2 Concepts Guide:
Dans le Guide d'optimisation des performances 11.2:
Dans le Guide de l'administrateur 11.2:
la source
Même avec tous les liens ci-dessus, vous devez regarder ce que Kimberly Tripp a écrit concernant les soins, l'alimentation et l'utilisation des index.
Pour commencer, suivez ce lien vers la collection de Kimberly de ses articles de blog liés à l'index. Vous pouvez explorer des sujets spécifiques en utilisant les widgets "Sur cette page" et "Catégories" sur le côté gauche de la fenêtre de votre navigateur.
Il y a beaucoup d'informations ici, mais ne vous laissez pas intimider.
La page À propos de Kimberly est ici
la source
Voici quelques ressources supplémentaires qui pourraient vous être utiles si vous travaillez avec SQL Server:
la source