Comment est-il erroné d'avoir un index unique et normal sur la même colonne?

Question

J'ai la structure de table suivante

CREATE TABLE `table` (
  `id` int(11) NOT NULL auto_increment,
  `date_expired` datetime NOT NULL,
  `user_id` int(11) NOT NULL,
  `foreign_id` int(11) NOT NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `date_expired` (`date_expired`,`user_id`,`foreign_id`),
  KEY `user_id` (`user_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Comme vous le remarquerez, j'ai des index en double sur l'id utilisateur: date_expired & amp; id_utilisateur . Je souhaite bien sûr l’index unique, car je veux que les données soient uniques.

La raison des index en double est que, sans l'index id_utilisateur , ma requête de recherche principale prend 4 secondes. Avec l'index supplémentaire, cela prend 1 seconde. La requête rejoint la table sur user_id et vérifie date_expired .

La table ne compte que 275 enregistrements.

• Quelle est la gravité d'avoir un index unique et normal sur le même champ?
• Est-il mauvais d'avoir des index plus volumineux que des données lorsque la table est purement id?

Answer 1

Je crois que si vous avez créé votre index unique sous la forme ( id_utilisateur , expiré par la date , id_étranger ), vous aurez le même avantage d'avoir un index normal sur user_id avec seulement l'index unique. MySQL peut utiliser les premières colonnes d’un index pour réduire le nombre de lignes de la jointure de la même manière qu’un index sur id_utilisateur .

Voir Documentation sur les index de MySQL pour plus d'informations. informations.

Faites-vous référence à la colonne id auto_increment ailleurs dans votre schéma pour économiser de l'espace? Étant donné que votre index unique couvre toutes les autres colonnes de votre table, il s’agit essentiellement d’une clé primaire et peut être supprimée si vous ne le faites pas.

Vous pouvez vérifier les clés utilisées par votre requête en la préfixant par EXPLAIN.

Answer 2

Je ne comprends pas ce que vous entendez par index en double. Vous avez trois index dans la table:

1. Un pour la clé primaire 'id' (ce qui implique unique)
2. Une autre solution unique pour la combinaison de 'date_expired', 'user_id' et 'foreign_id'
3. Et un troisième sur "user_id" uniquement

donc, il n'y a pas de duplication, vous avez trois index différents qui feront des choses différentes. Vous avez besoin du numéro 3 pour accélérer les requêtes liées à user_id, ce que vous voyez. Donc, il n'y a rien de mal avec cette table en particulier, vous ne dupliquez rien. En ce qui concerne la deuxième question, cela dépend de vos besoins, mais il n’est certainement pas mauvais d’avoir plus d’espace utilisé dans les index que dans les données.

Ce qui serait dommage, par exemple, est d’avoir un UNIQUE ('id_utilisateur') et plus tard une KEY ('id_utilisateur') (je ne suis même pas sûr que MySQL le permettra) car un index contiendrait l’autre et il n'y a rien à gagner.

Answer 3

Avoir plusieurs index dont un champ n'est pas mal du tout (ils indexent des choses différentes). Cela a un léger impact sur les performances en écriture, mais c'est le compromis typique que vous avez avec chaque indice en premier lieu. Avoir des index consommant plus d'espace que les données elles-mêmes n'est pas mauvais si l'espace est bon marché. Dans votre cas, cela devrait être bon marché compte tenu du fait que vous avez un très petit nombre d'entrées.

La question que je vous poserais dans votre position est la suivante: comment l’indexation d’une si petite table affecte-t-elle si sévèrement l’exécution de ma requête? Peut-être que vous faites quelque chose de mal (je pense à beaucoup de requêtes potentiellement redondantes à cette table), puisqu'un seul devrait être loin de cette période avec ce petit nombre d'entrées).