Maison  >  Article  >  base de données  >  Raisons et solutions pour lesquelles MySQL ne peut pas créer de clés étrangères

Raisons et solutions pour lesquelles MySQL ne peut pas créer de clés étrangères

小云云
小云云original
2017-12-08 13:15:311455parcourir

Cet article présente principalement les raisons et les solutions de l'incapacité de MySQL à créer des clés étrangères, puis vous donne des informations opportunes sur l'incapacité de MySQL à créer des clés étrangères et à interroger les propriétés des clés étrangères. Les amis intéressés devraient y jeter un œil.

Lors de l'association de deux tables, les clés étrangères ne peuvent pas être créées. Sur ce blog, nous pouvons voir que le problème réside dans la cohérence des options Charset et Collate du point 6 au niveau de la table et au niveau du champ. Le jeu de caractères d'encodage et l'assemblage de mes deux tables sont incohérents et les deux tables exécutent l'instruction SQL :

alter table 表名 convert to character set utf8;

Résout parfaitement le problème ; 🎜>

ps : Jetons un coup d'œil à l'incapacité de MySQL à créer des clés étrangères et à interroger les attributs des clés étrangères

Explication MyISAM et InnoDB

InnoDB et MyISAM sont les deux types de tables les plus couramment utilisés par de nombreuses personnes lors de l'utilisation de MySQL. Les deux types de tables ont leurs propres avantages et inconvénients, selon l'application spécifique. La différence fondamentale est la suivante : le type MyISAM ne prend pas en charge le traitement avancé tel que le traitement des transactions, contrairement au type InnoDB. La table de type MyISAM met l'accent sur les performances et ses temps d'exécution sont plus rapides que le type InnoDB, mais elle ne fournit pas de prise en charge des transactions, tandis qu'InnoDB fournit une prise en charge des transactions et des fonctions de base de données avancées telles que les clés étrangères.

 

Voici quelques détails et différences spécifiques d'implémentation :

 ◆1.InnoDB ne prend pas en charge les index de type FULLTEXT.

 ◆2. InnoDB n'enregistre pas le nombre spécifique de lignes dans la table, c'est-à-dire que lors de l'exécution de select count(*) from table, InnoDB doit analyser la table entière pour calculer le nombre de lignes qu'elle contient. le sont, mais MyISAM n'a besoin que d'une simple lecture du nombre de lignes enregistrées. Notez que lorsque l'instruction count(*) contient une condition Where, les opérations des deux tables sont les mêmes.

 ◆3. Pour les champs de type AUTO_INCREMENT, InnoDB doit contenir un index avec uniquement ce champ, mais dans la table MyISAM, un index conjoint peut être établi avec d'autres champs.

 ◆4. Lors de la suppression de la table, InnoDB ne recréera pas la table, mais la supprimera ligne par ligne.

 ◆5. L'opération LOAD TABLE FROM MASTER ne fonctionne pas pour InnoDB La solution consiste d'abord à changer la table InnoDB en table MyISAM, puis à la changer en table InnoDB après avoir importé les données. pour les tables supplémentaires utilisées par InnoDB avec des attributs (tels que les clés étrangères) ne s'appliquent pas.

De plus, le verrouillage des lignes de la table InnoDB n'est pas absolu. Si MySQL ne peut pas déterminer la plage à analyser lors de l'exécution d'une instruction SQL, la table InnoDB verrouillera également la table entière, par exemple la table de mise à jour. set num=1 où le nom ressemble à « %aaa% »

La principale différence entre les deux types est qu'Innodb prend en charge le traitement des transactions, les clés étrangères et les verrous au niveau des lignes. MyISAM ne le prend pas en charge. Par conséquent, MyISAM est souvent considéré comme ne pouvant être utilisé que dans de petits projets.

Du point de vue des utilisateurs qui utilisent MySQL, Innodb et MyISAM sont tous deux préférés. Si la plate-forme de base de données veut répondre aux exigences : stabilité de 99,9 %, évolutivité pratique et haute disponibilité, MyISAM est certainement le meilleur choix. choix.

Les raisons sont les suivantes :

1. La plupart des projets menés sur la plateforme sont des projets avec plus de lectures et moins d'écritures, et les performances en lecture de MyISAM sont bien mieux qu'Innodb.

2. L'index et les données de MyISAM sont séparés et l'index est compressé, ce qui augmente en conséquence l'utilisation de la mémoire. Il peut charger plus d'index, et l'index et les données d'Innodb sont étroitement liés. Aucune compression n'est utilisée, ce qui rendra Innodb beaucoup plus grand que MyISAM.

3. Il arrive souvent tous les 1 ou 2 mois qu'un développeur d'application mette accidentellement à jour une table et écrit la mauvaise plage, ce qui empêche l'utilisation normale de la table. À ce moment-là, la supériorité de MyISAM se reflète. . Retirez simplement le fichier correspondant à la table du package compressé copié ce jour-là, placez-le dans un répertoire de base de données, puis sauvegardez-le dans SQL et réimportez-le dans la base de données principale, et remplissez le binlog correspondant. S'il s'agit d'Innodb, je crains que cela ne puisse pas être aussi rapide. Ne me dites pas de demander à Innodb d'utiliser régulièrement le mécanisme d'exportation xxx.sql pour sauvegarder, car la plus petite instance de base de données a un volume de données de plusieurs dizaines de gigaoctets. .

4. Du point de vue de la logique de l'application, select count(*) et order by sont les opérations les plus fréquentes, représentant plus de 60 % du total des instructions SQL, et ce type d'opération Innodb en fait peut verrouille également les tables Beaucoup de gens pensent qu'Innodb est un verrou au niveau de la ligne, qui n'est valable que là où sa clé primaire verrouillera la table entière.

5. Il y a souvent de nombreux services d'application qui ont besoin que je leur fournisse régulièrement des données sur certaines tables. MyISAM est très pratique. Envoyez-leur simplement les fichiers frm.MYD et MYI correspondant à cette table et laissez-les vous. Vous pouvez simplement démarrer vous-même la base de données de la version correspondante, mais Innodb doit exporter xxx.sql, car le simple fait de donner le fichier à d'autres ne pourra pas l'utiliser en raison de l'influence du fichier de données du dictionnaire.

6. Si on le compare à MyISAM pour les opérations d'écriture d'insertion, Innodb ne peut toujours pas atteindre les performances d'écriture de MyISAM s'il s'agit d'opérations de mise à jour basées sur un index, bien que MyISAM puisse être inférieur à Innodb, mais avec une concurrence aussi élevée. écrit, La question de savoir si la base de données esclave peut rattraper son retard est également un problème. Il est préférable de le résoudre via une architecture de sous-base de données et de sous-tables multi-instances.

7. Si MyISAM est utilisé, le moteur de fusion peut accélérer considérablement le développement du département d'application. Il leur suffit d'effectuer quelques opérations de comptage sélectionné (*) sur cette table de fusion, ce qui est très approprié pour les grands. projets avec un montant total d'environ des centaines de millions de lignes. Un tableau commercial d'un certain type (tel que des journaux, des statistiques d'enquête).

  当然Innodb也不是绝对不用,用事务的项目就用Innodb的。另外,可能有人会说你MyISAM无法抗太多写操作,但是可以通过架构来弥补。

SELECT * FROM information_schema.key_column_usage WHERE table_name='表名' ;
show create table 表名 ;

MySQL学习之外键的图文详解

有关MySQL数据库中的外键约束详解

MySQL 的外键与参照完整性: Part 1_PHP教程

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn