Index MySQL 5.0 - Unique vs Non Unique
Quelle est la différence entre l'index unique et non unique de MySQL en termes de performances?
Disons que je veux faire un index sur un combo de 2 colonnes, et la combinaison est unique, mais je crée un index non unique. Cela aura-t-il un effet significatif sur les performances ou la mémoire utilisée par MySQL?
Même question, y a-t-il une différence entre la clé primaire et l'index nique?
UNIQUE et PRIMARY KEY sont des contraintes , pas des index. Bien que la plupart des bases de données implémentent ces contraintes à l'aide d'un index. La surcharge supplémentaire de la contrainte en plus de l'index est insignifiante, en particulier lorsque vous comptez le coût de la recherche et de la correction des doublons involontaires quand (pas si) ils se produisent.
Les index sont généralement plus efficaces si vous avez une sélectivité élevée . Il s'agit du rapport entre le nombre de valeurs distinctes et le nombre total de lignes.
Par exemple, dans une colonne pour le numéro de sécurité sociale, vous pouvez avoir 1 million de lignes avec 1 million de valeurs distinctes. La sélectivité est donc 1000000/1000000 = 1.0 (bien qu'il existe de rares exceptions historiques, les SSN sont censés être uniques).
Mais une autre colonne de ce tableau, "sexe" peut avoir seulement deux valeurs distinctes sur 1 million de lignes. 2/1000000 = très faible sélectivité.
Un index avec une contrainte UNIQUE ou PRIMARY KEY est garanti d'avoir une sélectivité de 1.0, il sera donc toujours aussi efficace qu'un index peut l'être.
Vous avez demandé la différence entre une clé primaire et une contrainte unique. Principalement, c'est que vous ne pouvez avoir qu'une seule contrainte de clé primaire par table (même si la définition de cette contrainte comprend plusieurs colonnes), alors que vous pouvez avoir plusieurs contraintes uniques. Une colonne avec une contrainte unique peut autoriser les valeurs NULL, tandis que les colonnes dans les contraintes de clé primaire ne doivent pas autoriser les valeurs NULL. Sinon, la clé primaire et l'unique sont très similaires dans leur mise en œuvre et leur utilisation.
Vous avez demandé dans un commentaire s'il fallait utiliser MyISAM ou InnoDB. Dans MySQL, ils utilisent le terme moteur de stockage . Il existe de nombreuses différences subtiles entre ces deux moteurs de stockage, mais les principaux sont:
- InnoDB prend en charge les transactions, vous pouvez donc choisir d'annuler ou de valider les modifications. MyISAM est en effet toujours automatiquement engagé.
- InnoDB applique des contraintes de clé étrangère. MyISAM n'applique ni ne stocke même les contraintes de clé étrangère.
Si ces fonctionnalités sont des éléments dont vous avez besoin dans votre application, vous devez utiliser InnoDB.
Pour répondre à votre commentaire, ce n'est pas si simple. InnoDB est en fait plus rapide que MyISAM dans de nombreux cas, cela dépend donc de la combinaison de sélections, mises à jour, requêtes simultanées, index, configuration de tampon de votre application, etc.
Voir http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/ pour une comparaison très approfondie des performances des moteurs de stockage . InnoDB gagne MyISAM assez souvent pour qu'il ne soit clairement pas possible de dire que l'un est plus rapide que l'autre.
Comme pour la plupart des questions liées aux performances, la seule façon d'y répondre pour votre application est de tester les deux configurations à l'aide de votre application et d'un échantillon représentatif de données, et mesurer les résultats.
Sur un index non unique qui se trouve être unique et un index unique? Je ne suis pas sûr, mais je suppose que pas beaucoup. L'optimiseur doit examiner la cardinalité de l'index et l'utiliser (ce sera toujours le nombre de lignes, pour un index unique).
En ce qui concerne une clé primaire, probablement beaucoup, mais cela dépend du moteur que vous utilisez.
Le moteur InnoDB (utilisé par de nombreuses personnes) regroupe toujours les lignes sur la clé primaire. Cela signifie que le PK est essentiellement combiné avec les données de ligne réelles. Si vous effectuez beaucoup de recherches par PK (ou en effet, des analyses de plage, etc.), c'est une bonne chose, car cela signifie qu'il n'aura pas besoin de récupérer autant de blocs du disque.
Un index unique non PK ne sera jamais mis en cluster dans InnoDB.
D'un autre côté, certains autres moteurs (MyISAM en particulier) ne regroupent pas le PK, donc la clé primaire est comme un index unique normal.