MySQL が外部キーを作成できない理由と解決策

この記事では、MySQL が外部キーを作成できない原因と解決策を主に紹介し、その後、MySQL が外部キーを作成できないことと、外部キーのプロパティをクエリすることについてのタイムリーな知識を提供します。興味のある方はぜひご覧ください。

2 つのテーブルを関連付ける場合、外部キーを作成できません。このブログから、ポイント 6 のテーブル レベルとフィールド レベルでの Charset オプションと Collat​​e オプションの一貫性に問題があることがわかります。 2 つのテーブルのエンコード文字セットと照合順序が矛盾しており、両方のテーブルで SQL ステートメントが実行されます:

alter table 表名 convert to character set utf8;

問題は完全に解決されます

ps: 以下で、MySQL が外部キーを作成したり、外部キーをクエリしたりできないことを見てみましょう。 .

MyISAM と InnoDB のプロパティについて説明しました

InnoDB と MyISAM は、MySQL を使用するときに多くの人が最もよく使用する 2 つのテーブル タイプであり、特定のアプリケーションに応じて、それぞれ長所と短所があります。基本的な違いは、MyISAM タイプはトランザクション処理などの高度な処理をサポートしないのに対し、InnoDB タイプはサポートするということです。 MyISAM タイプのテーブルはパフォーマンスを重視しており、その実行時間は InnoDB タイプよりも高速ですが、トランザクション サポートは提供されていません。一方、InnoDB はトランザクション サポートと外部キーなどの高度なデータベース機能を提供します。

以下は詳細と具体的な実装の違いです:

◆1. InnoDB は FULLTEXT 型インデックスをサポートしません。

◆2. InnoDB はテーブル内の特定の行数を保存しません。つまり、テーブルから select count(*) を実行するとき、InnoDB はテーブル全体をスキャンして行数を計算する必要がありますが、MyISAM はテーブル全体をスキャンする必要があります。単純に読み取って保存するだけで十分です。 count(*) ステートメントに where 条件が含まれている場合、2 つのテーブルの操作は同じであることに注意してください。

◆3. AUTO_INCREMENT 型のフィールドの場合、InnoDB ではこのフィールドのみのインデックスを含める必要がありますが、MyISAM テーブルでは他のフィールドとの結合インデックスを確立できます。

◆4. DELETE FROM tableを実行すると、InnoDBはテーブルを再作成せず、行ごとに削除します。

◆5. LOAD TABLE FROM MASTER 操作は InnoDB では機能しません。ただし、追加の InnoDB の場合は、まず InnoDB テーブルを MyISAM テーブルに変更します。使用される機能 (外部キーなど) テーブルは適用されません。

さらに、InnoDB テーブルの行ロックは絶対的ではありません。MySQL が SQL ステートメントの実行時にスキャンする範囲を決定できない場合、InnoDB テーブルはテーブル全体もロックします (たとえば、テーブル セット num=1 を更新します)。 where name like “%aaa %”

この 2 つのタイプの主な違いは、Innodb がトランザクション処理、外部キー、行レベルのロックをサポートしていることです。 MyISAM はこれをサポートしていません。そのため、MyISAM は小規模なプロジェクトでのみ使用するのに適していると考えられています。

MySQL を使用するユーザーの観点からは、Innodb と MyISAM の両方が推奨されます。データベース プラットフォームが 99.9% の安定性、便利なスケーラビリティ、高可用性の要件を満たす必要がある場合は、間違いなく MyISAM が第一の選択肢です。

理由は以下のとおりです:

1. プラットフォーム上で行われるプロジェクトのほとんどは、読み取りが多く書き込みが少ないプロジェクトであり、MyISAM の読み取りパフォーマンスは Innodb よりもはるかに優れています。

2. MyISAMはインデックスとデータが分離されており、インデックスが圧縮されているため、その分メモリ使用量が増加します。より多くのインデックスをロードでき、Innodb のインデックスとデータは緊密にバインドされます。圧縮は使用されないため、Innodb のサイズは MyISAM よりもはるかに大きくなります。

3. アプリケーション開発者が誤って間違った範囲に書き込まれたテーブルを更新してしまい、テーブルが正常に使用できなくなることは1～2ヶ月に一度よく起こりますが、この時にMyISAMの優位性が反映されます。その日にコピーした圧縮パッケージから対応するテーブルのファイルを取り出し、それをデータベース ディレクトリに置き、それを SQL にダンプしてメイン データベースにインポートし直し、対応するバイナリ ログに記入します。 Innodb の場合は、それほど高速ではないと思いますが、最小のデータベース インスタンスのデータ量は数十ギガバイトであるため、Innodb に定期的にバックアップ xxx.sql メカニズムを使用するように依頼しないでください。 。

4. アプリケーションロジックの観点から見ると、select count(*) と order by は最も頻繁に実行される操作であり、Innodb は実際にそのような操作のためにテーブルをロックします。 Innodb は行レベルのロックであり、where の主キーに対してのみ有効であり、非主キーに対してはテーブル全体がロックされると考えてください。

5. 特定のテーブルのデータを定期的に提供する必要があるアプリケーション部門も多くあります。MyISAM は、そのテーブルに対応する frm.MYD、MYI ファイルを送信するだけで非常に便利です。対応するバージョンを自分で作成します。データベースを起動するだけですが、ファイルを他人に渡すだけでは辞書データ ファイルの影響で使用できないため、Innodb は xxx.sql をエクスポートする必要があります。

6. 挿入書き込み操作の MyISAM と比較すると、Innodb はまだ MyISAM の書き込みパフォーマンスに到達できません。インデックスベースの更新操作の場合、MyISAM は Innodb より劣るかもしれませんが、スレーブ データベースはこのような高い同時書き込みを実行できますか。追いつくことも問題です。これは、マルチインスタンスのサブデータベースとサブテーブルのアーキテクチャを通じて解決する方が良いでしょう。

7. MyISAM を使用すると、マージ エンジンは、このマージ テーブルに対していくつかの選択カウント (*) 操作を実行するだけで済み、アプリケーション部門の開発速度を大幅に高速化できます。特定のタイプ (ログ、調査統計など) のビジネス テーブルの数億行の総数。

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

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

MySQL学习之外键的图文详解

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

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

以上がMySQL が外部キーを作成できない理由と解決策の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。