mysql外部キーエラー1005 errno 150

https://stackoverflow.com/questions/4063141

27-09-2019
|

質問

MySQLワークベンチを使用して小さなデータベースを行っています。「Immobili」と呼ばれるメインテーブルがあります。これには、4つの列で構成された主要なキーがあります（Comune、Via、Civico、Immobile）。

現在、私は他の3つのテーブルも持っています。

最初の質問：外部キーでもある主要な鍵を作ることはできますか？

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の外部キー制約のエラー：

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

私がどこで間違っているの？

解決

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

テストケース：

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)

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

他のヒント

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

私はこれが古い投稿であることを認識していますが、Googleでランク付けされているので、自分の問題のために理解したものを追加しています。テーブルタイプ（MyisamとInnodbなど）が混在している場合、このエラーも取得されます。この場合、InnoDBはデフォルトのテーブルタイプですが、1つのテーブルがフルテキスト検索を必要とするため、Myisamに移行しました。この状況では、Myisamテーブルを参照するInnoDBテーブルに外部キーを作成することはできません。

キーがchar/varcharまたはそのタイプの何かである場合、別の可能な問題は異なる照合です。チャーセットが同じかどうかを確認してください。

このエラーがあり、私の場合のエラーの理由が見つかりました。 Googleでかなり高いランク付けであるため、この古い投稿にまだ答えています。

リンクしたかった両方の列の変数は整数でしたが、INTの1つは「署名されていない」チェックオンでした。単に私のエラーを修正したチェックを解除するだけです。

同じエラーが発生していました。メインテーブルの主要なキーを作成したソリューションをBigintとして署名していないため、2番目のテーブルの外部キーとしてBigintのみとして宣言していました。

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

ですから、それは主キーと外部キーの間のデータ型の不一致でした:)

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

その状況に具体的なものに私の外部鍵を改名すると、問題が解決されました。

両方のテーブルが同じエンジンタイプを使用していることを確認してください。
インデックス作成のフィールドが同じタイプと長さを持っていることを確認してください。

私の場合、エラーは次のとおりでした referencing テーブルはです MyISAM 一方 referring テーブルはそうでした InnoDB.

Converted テーブルエンジンから MyISAM to InnoDB 私のために問題を解決します。

ALTER TABLE table_name ENGINE=InnoDB;

私はまだスティーブの提案に投票する評判を持っていませんが、それは私の問題を解決しました。

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

以下を使用してデータベースタイプを変更できます。テーブルTエンジン= myisamを変更します。

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

注意してください 文字コード と 照合します テーブルを作成するときのパラメーター。 外部キーに関して そのような問題：

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

私の場合、外部のキー参照を使用してテーブルを作成できませんでした。最初に、エラーコード1005を取得しました。それで 照合を追加しました そして最後に、charsetについて不平を言うエラーメッセージ。

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

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

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

fk/pk関係がよく形成されているこのエラーがある場合は、視覚ツールを使用した場合は、問題のあるFK列を削除してツールで再添加してみてください。問題が解消された接続を再縮小するまで、私はこのエラーを継続的に取得していました。

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

私にとって、私は子テーブルの通常のインデックスフィールドを親テーブルの主要なキーに一致させようとしていました。チャイルドテーブルフィールドも署名されていないこと（これらのフィールドに負のINTが含まれている場合を除き、両方が署名されていることを確認してください）。

MySQLは、特に外国の鍵やトリガーに関しては、不機嫌に気づきます。私は今、そのようなデータベースの1つを微調整する過程にあり、この問題に遭遇しました。それは自己明白でも直感的でもないので、ここに行きます：

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

良い習慣は、関係に関係するテーブルをクリーンアップして、以前の試みが望まない、または必要としないインデックスを作成しないようにすることです。

それが役立ったことを願っています、いくつかのMySQLエラーは追跡するのが狂っています。

最初の質問：外部キーでもある主要な鍵を作ることはできますか？

はい。実際、MySQL Workbenchの場合、私は外部キーに主要なキーのみを使用する習慣になりました。 ERR：150が質問に記載されているように、受信したランダムなエラーを本当に削減します。

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

これには、インデックス、またはより具体的にはMySQLワークベンチがどのように解釈され、それらと連携するかを備えたものがあります。モデル（外国の鍵、インデックス、col注文など）ですべてが同じ前方エンジニアリング操作で多くを変更すると、本当に混乱します。 特に反対側にすでにデータベースがある場合. 。たとえば、外部キーを削除した後に自動的に削除されたインデックスが自動的に作成されたとは思わない。

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

1.ルックアップテーブルですべての外部キーを主要なキー（1から1に1つに）にします。

私の場合、これには、IDをtbl_usersのユーザー名、tbl_companiesのユーザー名と会社に変更し、tbl_company_contactsのユーザー名と会社と連絡先に変更することが含まれていました。複数のユーザーが複数の企業の連絡先を入力するためのアプリであり、他のユーザーの連絡先の重複と隠蔽を可能にします。

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

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

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

これにより、DB、サーバー、MySQLのワークベンチが大いに作らなければならないという決定の多くが減少します。何かをエンジニアリングする方法についてのこれらの決定は、複雑で知的ですが、不完全です。

4.次に、これを正方形に戻すことを検討します（一般に、段階的なプロセスなしであまりにも速く設計した後）。私はまだすべてのテーブルを持っていますが、この段階ではきれいです。今あなただけ：

まず、テーブル（関係のない）が予想どおりに機能することを確認するためだけに、フォワードエンジニア。

主要なキーを通して関係チェーンをフォローして、最も上のテーブルから始めています（私はTBL_COMPANIESのTBL_USERSです）。それぞれの関係の後、常にそれを確認するためにエンジニアを転送します実行, 、次にモデルを保存して閉じてから、モデルをリバースエンジニアリングして確認してください取る. 。これにより、問題が発生したときに迅速に隔離できます。私の場合、古い削除された外国の鍵で使用されているインデックスが残っています（2〜3回発生します）。

そしてタッダ、あなたがいる必要がある場所に戻って。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow