Avez-vous des raisons de croire que MySQL autorisera jamais des clés étrangères sur des colonnes non indexées pour tout autre type de table?
Robert Gamble
Je ne pouvais vraiment pas répondre à cela. Vous pouvez rechercher les moteurs de stockage Maria et Falcon qui doivent être publiés dans MySQL 6.0 et voir s'ils prennent en charge les clés étrangères sur les colonnes non indexées.
Grant Limberg
Apparemment, ce n'est pas vrai. J'ai une grande table (1 million d'enregistrements) et compte (*) où fkey =? prendrait 15 secondes. Ajout d'un index sur la colonne fkey, et les choses passent sous une seconde maintenant.
AbiusX
Même expérience avec une autre table et 10 millions d'enregistrements. C'est ofc MySQL 5.1 InnoDB. La table comporte trois champs, l'un est un entier de clé primaire, l'autre est déjà indexé. Le troisième était une clé étrangère à la clé primaire d'une autre table. Sans ajouter d'index explicite, les recherches ont pris plusieurs secondes ici. Afficher l'index de la table n'a pas non plus affiché d'index dessus.
AbiusX
@AbiusX 5.1 est probablement trop ancien, voir la réponse de MrAlexander ci-dessous.
InnoDB nécessite des index sur les clés étrangères et les clés référencées afin que les vérifications de clés étrangères puissent être rapides et ne nécessitent pas une analyse de table. Dans la table de référence, il doit y avoir un index dans lequel les colonnes de clé étrangère sont répertoriées en tant que premières colonnes dans le même ordre. Un tel index est créé automatiquement sur la table de référencement s'il n'existe pas. (Cela contraste avec certaines versions plus anciennes, dans lesquelles les index devaient être créés explicitement ou la création de contraintes de clé étrangère échouait.) Nom_index, s'il est indiqué, est utilisé comme décrit précédemment.
+1 bien meilleure réponse que celle sélectionnée comme le prouve la documentation
Gaz_Edge
6
Le texte cité ne semble plus être inclus dans les documents MySQL, ce qui ne permet pas de savoir si cela est toujours vrai ou non.
Courtney Miles
7
@ user2045006 vous pouvez vous référer au doc 5.0 ainsi qu'au doc 5.6 pour le texte cité
sactiw
1
Dans les documents actuels, il y a juste un léger changement dans le texte (je suppose que le sens est similaire):InnoDB permits a foreign key to reference any index column or group of columns. However, in the referenced table, there must be an index where the referenced columns are the first columns in the same order.
Cette réponse est un excellent exemple de la raison pour laquelle une réponse ne devrait jamais consister uniquement en un lien vers une réponse possible. En ce moment, la page liée ne répond pas du tout à la question.
Mike
1
Veuillez ajouter toutes les informations à la réponse elle-même au lieu de publier uniquement un lien
Nico Haase
11
Vous n'obtenez pas l'index automatiquement si vous faites une ALTER TABLE (au lieu de CREATE TABLE), au moins selon les documents (le lien est pour 5.1 mais c'est la même chose pour 5.5):
[...] Lorsque vous ajoutez une contrainte de clé étrangère à une table à l'aide de ALTER TABLE, n'oubliez pas de créer d'abord les index requis.
J'ai également essayé sur MySQL 5.6 et MariaDB 10 et ALTER TABLE a créé un index. Il est intéressant de noter que mysqlindexcheck a signalé que cet index était un "index redondant". J'ai essayé de le supprimer mais j'ai eu l'erreur suivante: "ERREUR 1553 (HY000): impossible de supprimer l'index 'nom_index': nécessaire dans une contrainte de clé étrangère". Il n'est donc pas possible de supprimer cet index et de conserver la clé étrangère.
Ciprian Stoica
Vous voudrez peut-être réviser votre réponse. MySQL crée toujours un index pour accélérer les vérifications de clés étrangères s'il n'en existe pas déjà . Les documents tentent de vous dire que la création d'index avant les contraintes de clé étrangère peut accélérer un peu les choses. Par exemple, un index de clé composite qui pourrait servir d'index pour les vérifications de clé étrangère pourrait être utilisé par InnoDB au lieu de générer automatiquement un index redondant.
BMiner
7
Pour ceux qui recherchent des devis de 5.7documents :
MySQL nécessite des index sur les clés étrangères et les clés référencées afin que les vérifications de clés étrangères puissent être rapides et ne nécessitent pas une analyse de table. Dans la table de référence, il doit y avoir un index dans lequel les colonnes de clé étrangère sont répertoriées en tant que premières colonnes dans le même ordre. Un tel index est créé automatiquement sur la table de référencement s'il n'existe pas. Cet index peut être supprimé silencieusement ultérieurement, si vous créez un autre index qui peut être utilisé pour appliquer la contrainte de clé étrangère. nom_index, s'il est donné, est utilisé comme décrit précédemment.
Comme indiqué, c'est le cas pour InnoDB. Au début, je pensais que c'était étrange que beaucoup d'autres (en particulier MS SQL et DB2) ne le fassent pas. Les analyses TableSpace ne sont meilleures que les analyses d'index lorsqu'il y a très peu de lignes de table - donc dans la grande majorité des cas, une clé étrangère voudrait être indexée. Ensuite, cela m'a frappé - cela ne signifie pas nécessairement qu'il doit s'agir d'un index autonome (une colonne) - où il se trouve dans l'index FK automatique de MySQL. Donc, c'est peut-être la raison pour laquelle MS SQL, DB2 (Oracle, je ne suis pas sûr), etc., laissent le DBA; après tout, plusieurs index sur de grandes tables peuvent entraîner des problèmes de performances et d'espace.
Vous soulevez un bon point sur les index de clés composites; cependant, MySQL supprimera automatiquement / silencieusement un index de clé unique généré automatiquement si un index de clé composite nouvellement créé remplit l'obligation de rendre les contrôles de clé étrangère rapides. Pour être honnête, je n'ai aucune idée pourquoi MS SQL, DB2 et d'autres ne le font pas. Ils ont peu d'excuse. Je ne peux pas penser à un cas d'utilisation où un index généré automatiquement sur des clés étrangères serait nuisible.
BMiner
2
Oui, Innodbfournissez ceci. Vous pouvez mettre un nom de clé étrangère après la FOREIGN KEYclause ou le laisser pour laisser MySQL créer un nom pour vous. MySQL crée automatiquement un index avec le foreign_key_namenom.
Apparemment, un index est créé automatiquement comme spécifié dans le lien que Robert a publié .
Contraintes InnoDB et FOREIGN KEY
la source
InnoDB permits a foreign key to reference any index column or group of columns. However, in the referenced table, there must be an index where the referenced columns are the first columns in the same order.
Oui, voir InnoDB et FOREIGN KEY Constraints .
la source
Vous n'obtenez pas l'index automatiquement si vous faites une ALTER TABLE (au lieu de CREATE TABLE), au moins selon les documents (le lien est pour 5.1 mais c'est la même chose pour 5.5):
la source
Pour ceux qui recherchent des devis de
5.7
documents :la source
Comme indiqué, c'est le cas pour InnoDB. Au début, je pensais que c'était étrange que beaucoup d'autres (en particulier MS SQL et DB2) ne le fassent pas. Les analyses TableSpace ne sont meilleures que les analyses d'index lorsqu'il y a très peu de lignes de table - donc dans la grande majorité des cas, une clé étrangère voudrait être indexée. Ensuite, cela m'a frappé - cela ne signifie pas nécessairement qu'il doit s'agir d'un index autonome (une colonne) - où il se trouve dans l'index FK automatique de MySQL. Donc, c'est peut-être la raison pour laquelle MS SQL, DB2 (Oracle, je ne suis pas sûr), etc., laissent le DBA; après tout, plusieurs index sur de grandes tables peuvent entraîner des problèmes de performances et d'espace.
la source
Oui,
Innodb
fournissez ceci. Vous pouvez mettre un nom de clé étrangère après laFOREIGN KEY
clause ou le laisser pour laisser MySQL créer un nom pour vous. MySQL crée automatiquement un index avec leforeign_key_name
nom.la source
Oui, Mysql indexe automatiquement la clé étrangère lorsque vous créez une table qui a une clé étrangère vers une autre.
la source
Il n'est pas possible d'obtenir automatiquement la clé d'index
Nom du tableau que vous avez créé par exemple des photographies et CLÉ ÉTRANGÈRE par exemple
photograph_id
. Le code devrait être comme cecila source