les champs presque uniques doivent-ils avoir des index

Question

J'ai dans la base de données un champ presque unique: les valeurs sont uniques dans 98% des cas, mais il peut contenir quelques doublons. Je ne ferai pas beaucoup de recherches sur ce champ; dire deux fois par mois. La table contient actuellement environ 5 000 enregistrements et en gagnera environ 150 par mois.

Ce champ doit-il avoir un index?

J'utilise MySQL.

Answer 1

Je pense que le "presque unique" est probablement un piège rouge. Les données sont uniques ou non, mais cela ne détermine pas si vous souhaitez les indexer pour des raisons de performances.

Réponse:

5000 enregistrements, ce n’est vraiment pas beaucoup, et que vous ayez ou non un index, les recherches seront toujours rapides. Avec ce nombre d'inserts, il vous faudra 3 ans pour atteindre 10000 disques, ce qui n'est toujours pas beaucoup.
Personnellement, je ne me soucierais pas d'ajouter un index, mais cela n'aurait pas d'importance si vous le faisiez.

Explication:

Lorsque vous décidez d'ajouter un index, vous devez prendre en compte le compromis entre la vitesse d'insertion et la vitesse de sélection.

Sans index, effectuer un select sur ce champ signifie que MySQL doit parcourir chaque ligne et lire chaque champ. L’ajout d’un index l’empêche.

L’inconvénient de l’index est que chaque fois que des données sont insérées, la base de données doit mettre à jour l’index en plus d’ajouter les données. Il s’agit généralement d’une légère surcharge, mais vous le remarquerez vraiment si vous avez beaucoup d’index et que vous faites beaucoup d’écritures.

Au moment où vous obtenez autant de lignes dans votre base de données, vous voudriez quand même un index, sinon votre sélection prendrait toute la journée, mais il faut simplement être conscient de la situation pour ne pas ajouter d'index sur champs "juste au cas où j'en aurais besoin"

Answer 2

Ce n’est pas très volumineux; Je ne prendrais pas la peine de créer des index sur cette table. La singularité relative du champ n'a aucune importance - même sur du matériel standard vieux de plusieurs années, je m'attendrais à ce qu'une requête sur cette table prenne une fraction de seconde.

Answer 3

vous pouvez utiliser la règle générale: optimiser lorsque cela devient un problème. N'utilisez pas d'index tant que vous n'en avez pas besoin.

Answer 4

D'après ce que vous dites, il ne semble pas qu'un index soit nécessaire. La règle empirique est celle des champs d’index utilisés dans SELECTS pour accélérer la recherche, ce qui ralentit (can) les inserts et les mises à jour.

Sur un jeu d’enregistrements aussi petit que le vôtre, je ne pense pas que l’on verra grand chose du monde réel de toute façon.

Answer 5

Si vous ne faites que des recherches sur ce site deux fois par mois et sur quelques lignes, je vous prierais de ne pas l'indexer. C'est tout sauf inutile.

Answer 6

Non. Il n'y a pas beaucoup de disques et il ne sera pas fréquemment interrogé. Pas besoin d'indexer.

Answer 7

C'est vraiment un jugement. Avec une table aussi petite, vous pouvez effectuer une recherche raisonnablement rapidement sans index, vous pouvez donc vous en passer.

D'autre part, le coût de création d'un index dont vous n'avez pas vraiment besoin est plutôt faible, vous ne vous épargnerez donc pas beaucoup en ne le faisant pas.

De plus, si vous créez l'index, vous êtes assuré pour l'avenir si vous commencez soudainement à obtenir 1 000 nouveaux enregistrements / semaine. Peut-être que vous en savez assez sur la situation pour affirmer avec certitude que cela ne se produira jamais, mais que les exigences changent quand vous vous y attendez le moins.

EDIT: En ce qui concerne la modification des exigences, il convient de prendre en compte les éléments suivants: Si la base de données grossit et que vous découvrez plus tard que vous avez besoin d’un index, pouvez-vous simplement créer l’index et le faire? Ou devrez-vous également changer beaucoup de code pour utiliser le nouvel index?

Answer 8

Cela dépend. Comme d'autres ont répondu, il existe un compromis entre la vitesse de mise à jour des tables et la vitesse de sélection. La mise à jour de table inclut des insertions, des mises à jour et des suppressions sur la table.

Une question à laquelle vous n'avez pas répondu. La table a-t-elle une clé primaire et un index correspondant? Une table sans index bénéficie généralement d’avoir au moins un index. Le moyen le plus courant d’obtenir cet index est de déclarer une clé primaire et de s’appuyer sur le SGBD pour générer un index en conséquence.

Si une table n'a pas de candidats pour la clé primaire, cela indique généralement une faille grave dans la conception de la table. C’est une question distincte qui devrait faire l’objet d’une discussion approfondie.