web-dev-qa-db-ja.com

MySQL外部キーエラー1005 errno 150

MySQL Workbenchを使用して小さなデータベースを作成しています。 「Immobili」というメインテーブルがあり、4つの列（Comune、Via、Civico、Immobile）で構成されるプライマリキーがあります。

現在、他にも3つのテーブルがあり、同じプライマリキー（Comune、Via、Civico、Immobile）がありますが、これらのフィールドはテーブルImmobiliを参照しています。

最初の質問：外部キーでもある主キーを作成できますか？

2番目の質問：変更をエクスポートしようとすると、サーバーでSQLスクリプトを実行しています

# ERROR: Error 1005: Can't create table 'dbimmobili.condoni' (errno: 150)

CREATE  TABLE IF NOT EXISTS `dbimmobili`.`Condoni` (

  `ComuneImmobile` VARCHAR(50) NOT NULL ,
  `ViaImmobile` VARCHAR(50) NOT NULL ,
  `CivicoImmobile` VARCHAR(5) NOT NULL ,
  `InternoImmobile` VARCHAR(3) NOT NULL ,
  `ProtocolloNumero` VARCHAR(15) NULL ,
  `DataRichiestaSanatoria` DATE NULL ,
  `DataSanatoria` DATE NULL ,
  `SullePartiEsclusive` TINYINT(1) NULL ,
  `SullePartiComuni` TINYINT(1) NULL ,
  `OblazioneInEuro` DOUBLE NULL ,
  `TecnicoOblazione` VARCHAR(45) NULL ,
  `TelefonoTecnico` VARCHAR(15) NULL ,
  INDEX `ComuneImmobile` (`ComuneImmobile` ASC) ,
  INDEX `ViaImmobile` (`ViaImmobile` ASC) ,
  INDEX `CivicoImmobile` (`CivicoImmobile` ASC) ,
  INDEX `InternoImmobile` (`InternoImmobile` ASC) ,

  PRIMARY KEY (`ComuneImmobile`, `ViaImmobile`, `CivicoImmobile`, `InternoImmobile`) ,

  CONSTRAINT `ComuneImmobile`
    FOREIGN KEY (`ComuneImmobile` )
    REFERENCES `dbimmobili`.`Immobile` (`ComuneImmobile` )
    ON DELETE CASCADE
    ON UPDATE CASCADE,

  CONSTRAINT `ViaImmobile`
    FOREIGN KEY (`ViaImmobile` )
    REFERENCES `dbimmobili`.`Immobile` (`ViaImmobile` )
    ON DELETE CASCADE
    ON UPDATE CASCADE,

  CONSTRAINT `CivicoImmobile`
    FOREIGN KEY (`CivicoImmobile` )
    REFERENCES `dbimmobili`.`Immobile` (`CivicoImmobile` )
    ON DELETE CASCADE
    ON UPDATE CASCADE,

  CONSTRAINT `InternoImmobile`
    FOREIGN KEY (`InternoImmobile` )
    REFERENCES `dbimmobili`.`Immobile` (`InternoImmobile` )
    ON DELETE CASCADE
    ON UPDATE CASCADE
) ENGINE = InnoDB

エンジンステータスの表示：

テーブルdbimmobili/valutazionimercatoの外部キー制約のエラー：

参照されている列が最初の列として表示されているか、テーブルの列タイプが参照されているテーブルでインデックスが見つかりません。参照されているテーブルが制約に一致しません。 InnoDB-4.1.12で作成されたテーブルではENUMおよびSETの内部ストレージタイプが変更され、古いテーブルのそのような列は新しいテーブルのそのような列から参照できないことに注意してください。

どこで間違っていますか？

mysqlmysql-workbenchmysql-error-1005
38
IssamTP

外部キー制約を作成する場合、MySQLは参照テーブルと参照テーブルの両方で使用可能なインデックスを必要とします。参照テーブルのインデックスは存在しない場合は自動的に作成されますが、参照テーブルのインデックスは手動で作成する必要があります（ Source ）。不足しているようです。

テストケース：

CREATE TABLE tbl_a (
    id int PRIMARY KEY,
    some_other_id int,
    value int
) ENGINE=INNODB;
Query OK, 0 rows affected (0.10 sec)

CREATE TABLE tbl_b (
    id int PRIMARY KEY,
    a_id int,
    FOREIGN KEY (a_id) REFERENCES tbl_a (some_other_id)
) ENGINE=INNODB;
ERROR 1005 (HY000): Can't create table 'e.tbl_b' (errno: 150)

しかし、some_other_idにインデックスを追加すると：

CREATE INDEX ix_some_id ON tbl_a (some_other_id);
Query OK, 0 rows affected (0.11 sec)
Records: 0  Duplicates: 0  Warnings: 0

CREATE TABLE tbl_b (
    id int PRIMARY KEY,
    a_id int,
    FOREIGN KEY (a_id) REFERENCES tbl_a (some_other_id)
) ENGINE=INNODB;
Query OK, 0 rows affected (0.06 sec)

参照フィールドは参照テーブルの主キーであることが多く、主キーには自動的にインデックスが付けられるため、これはほとんどの状況で問題になりません。

50
Daniel Vassallo

外部キーがこのテーブルにあるフィールドとまったく同じタイプであることを再確認してください。たとえば、両方ともInteger（10）またはVarchar（8）であり、文字数でさえなければなりません。

30
dmp

これは古い投稿であることに気づきましたが、Googleで上位にランクされているので、私の問題で見つけたものを追加しています。テーブルタイプ（MyISAMとInnoDBなど）が混在している場合、このエラーも発生します。この場合、InnoDBはデフォルトのテーブルタイプですが、1つのテーブルが全文検索を必要としたため、MyISAMに移行されました。この状況では、MyISAMテーブルを参照するInnoDBテーブルに外部キーを作成できません。

15
Steve

キーがCHAR/VARCHARまたはそのタイプのキーである場合、別の考えられる問題は異なる照合です。文字セットが同じかどうかを確認してください。

9
Alon Diamant

このエラーが発生し、私の場合はエラーの理由を見つけました。この古い投稿はGoogleで非常に高いので、私はまだこの古い投稿に答えています。

リンクしたい両方の列の変数は整数でしたが、intの1つが「符号なし」にチェックされていました。単にチェックを外すだけでエラーが修正されました。

6
Wafje

同じエラーが発生していました。メインテーブルに主キーをBIGINT UNSIGNEDとして作成し、2番目のテーブルに外部キーとしてBIGINTのみとして宣言しているという解決策を見つけました。

2番目のテーブルで外部キーをBIGINT UNSIGEDとして宣言すると、すべてが正常に機能し、インデックスを作成する必要はありませんでした。

そのため、主キーと外部キーのデータ型が一致しませんでした:)

5
iltaf khalid

私はまったく同じ問題を抱えていましたが、私の問題の解決策は完全に異なっていました。データベース内のどこかに、同じ名前の外部キーがありました。これによりエラー1005が発生しました。

外部キーの名前をその状況に固有の名前に変更すると、問題は解決しました。

4
Sherlock
  1. 両方のテーブルが同じエンジンタイプを使用していることを確認してください。
  2. インデックスを作成するフィールドのタイプと長さが同じであることを確認してください。
3
Jason Rundell

私の場合、エラーはreferencingテーブルがMyISAMであったため、referringテーブルはInnoDBでした。

MyISAM to InnoDBのConvertedテーブルエンジンが問題を解決します。

ALTER TABLE table_name ENGINE=InnoDB;
3
Rizwan Mumtaz

[〜＃〜] charset [〜＃〜]および[〜＃〜] collat​​e [〜 ＃〜]テーブル作成時のパラメーター。 外部キーの問題では、次のような問題があります：

CREATE TABLE yourTableName (
....
....
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

私の場合、外部キー参照を持つテーブルを作成できませんでした。まず、ほとんど何も言わないエラーコード1005を受け取りました。次に、iはCOLLATEを追加し、最後にCHARSETについて不平を言っているエラーメッセージを追加しました。

Error Code: 1253. COLLATION 'utf8_unicode_ci' is not valid for CHARACTER SET 'latin1'

その修正の後、私の問題は解決されました。

1
sba

スティーブの提案に賛成票を投じる評判はまだありませんが、私の問題は解決しました。

私の場合、異なるデータベースエンジンを使用して作成された2つのテーブル（1つはInnodbと他のMyISAM）であるため、このエラーを受け取りました。

次を使用してデータベースタイプを変更できます。ALTER TABLE t ENGINE = MYISAM;

@see http://dev.mysql.com/doc/refman/5.1/en/storage-engine-setting.html

1
Fermentation

MySQLは、特に外部キーとトリガーに関して悪名高いです。私は今、そのようなデータベースを微調整する過程にあり、この問題に遭遇しました。それは自明または直感的ではないので、ここに行きます：

リレーションシップで参照する2つの列のデータ型が同じであるかどうかを確認することに加えて、参照するテーブルの列がインデックスであることも確認する必要があります。 MySQL Workbenchを使用している場合は、[列]の横にある[インデックス]タブを選択し、外部キーによって参照される列がインデックスであることを確認します。そうでない場合は、作成して意味のある名前を付け、タイプに「INDEX」を付けます。

リレーションシップに関係するテーブルをクリーンアップして、以前の試行で不要または不要なインデックスが作成されないようにすることをお勧めします。

うまくいけば、My​​SQLのエラーのいくつかを追跡するのが面倒になります。

0
Théo T. Carranza

私にとっては、子テーブルの通常のインデックス付きフィールドを親テーブルのプライマリキーに一致させようとしましたが、デフォルトでは、Sequel Proなどの一部のMySQLフロントエンドGUIがプライマリキーを符号なしとして設定するため、子テーブルフィールドも署名されていないこと（これらのフィールドに負のintが含まれている場合を除き、両方が署名されていることを確認してください）。

0
smo0f

特定のケースではありませんが、テーブルの主キー全体ではないテーブル内の一部のフィールドを参照しようとすると、このエラーが発生する可能性があることを他の人に注意する価値があります。明らかにこれは許可されていません。

0
bluish

最初の質問：外部キーでもある主キーを作成できますか？

はい。実際、MySQLワークベンチでは、外部キーに主キーのみを使用する習慣がつきました。質問に記載されているerr：150のように、受信したランダムエラーを本当に減らします。

＃エラー：エラー1005：テーブル 'dbimmobili.condoni'を作成できません（errno：150）

これは、インデックス、またはより具体的にはMySQLワークベンチがインデックスを解釈して動作させる方法に関係しています。同じフォワードエンジニアリング操作でモデルの多くの部分（外部キー、インデックス、列順序など）をすべて変更すると、本当に混乱します特にもう一方の端にデータベースがある場合。たとえば、外部キーを削除すると自動的に削除されるインデックスは自動的に作成されないと思います。

これは、受信エラーを修正するために私がしたことです。注意してください、それは面倒ですが、他の方法を使用して費やした時間と比較すると、そうではありません。

1。ルックアップテーブル内のすべての外部キーをプライマリキーにします（1対多の1）。

私の場合、これはpkのidをtbl_usersのユーザー名、tbl_companiesのユーザー名AND company、およびtbl_company_contactsのユーザー名AND company AND連絡先に変更する必要がありました。複数のユーザーが複数の会社の連絡先を入力するアプリで、他のユーザーの連絡先の重複や非表示を許可します。

2。すべての図の関係と、主キーではないすべてのテーブルインデックスを削除します。

これにより、バグの多いMySQLワークベンチによって実際に引き起こされるインデックスの問題のほとんどが修正されます。

。これを最初から最後まで行う場合は、サーバーにスキーマをドロップして、mysqlワークベンチが既存のインデックスについて混乱せず、モデル内に不足しないようにします（問題は、インデックスだけではなく、bbyインデックスと外部キーの関係が原因です）。

これにより、DB、サーバー、Mysqlワークベンチが多くの決定を下す必要がある多くの決定が削減されます。何かをフォワードエンジニアリングする方法に関するこれらの決定は、複雑でインテリジェントですが、不完全です。

4。今、私はこれを正方形に戻すことを考えます（通常、段階的なプロセスなしで非常に速く設計した後）。私はまだすべてのテーブルを持っていますが、この段階ではきれいです。今あなただけ：

最初に、テーブルが（関係なしで）期待どおりに機能することを確認するために、フォワードエンジニアリングを行います。

最上位のテーブルから開始して、主キーを介してリレーションシップチェーンをたどります（tbl_companiesの場合はtbl_usersです）。各関係の後、常にフォワードエンジニアリングしてrunsを確認し、モデルを保存して閉じ、モデルをリバースエンジニアリングしてそれを確認しますtakes。これにより、問題が発生したときに迅速に切り分けることができます。私の場合、古い削除済み外部キーで使用されていたインデックスが残っています（2〜3回発生）。

そして、タダ、あなたがいる必要がある場所に戻ります。

0
gunslingor

主キーに2つの列がある場合、それらは複合主キーを構成するため、参照されるテーブルには同じデータ型の2つの列もあることを確認する必要があります。

0
anesumushate

FK/PK関係のように見えるこのエラーが誰かにあり、視覚ツールを使用した場合は、問題のfk列を削除して、ツールに追加し直してください。問題を解決する接続を再描画するまで、このエラーが継続的に発生していました。

0
munch1324