web-dev-qa-db-ja.com

同じ列に外部キー制約とインデックスキーがある

2つの列の複合インデックスキーを作成し、外部キーを適切なテーブルに追加しています。複数のインデックスキー参照を作成してから、個別の外部キーを作成する必要がありますか？私がそれを達成した方法の私の例は以下です：

CREATE TABLE IF NOT EXISTS customers_appointments (
appointment_id int(11) NOT NULL PRIMARY KEY AUTO_INCREMENT,
merchant_id int(11) NOT NULL,
supplier_id int(11) NOT NULL,
appointment_date datetime NOT NULL,
appointment_description mediumtext NOT NULL,
appointment_confirmed tinyint(1) NOT NULL DEFAULT '0',
appointment_confirmed_date datetime NOT NULL,
date_created datetime NOT NULL
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

ALTER TABLE customers_appointments 
 ADD KEY appointments_index (merchant_id,supplier_id), 
 ADD KEY fk_merchant_appointment (merchant_id), 
 ADD KEY fk_supplier_appointment (supplier_id);

ALTER TABLE customers_appointments
  ADD CONSTRAINT fk_merchant_appointment 
    FOREIGN KEY (merchant_id) REFERENCES merchants (merchant_id) 
    ON DELETE CASCADE,
  ADD CONSTRAINT fk_supplier_appointment 
    FOREIGN KEY (supplier_id) REFERENCES suppliers (supplier_id) 
    ON DELETE CASCADE;

これは私にとってはうまくいきますが、パフォーマンスの面でそれがどのように設計されているかが正しいことを専門家から知る必要がありますか？

mysqldatabase-designindexforeign-key
3
Cam

制約とインデックスは、データベースで2つの異なる目的を果たします。

制約は、制約に違反するデータがデータベースに保存されるのを防ぎます。これはデータの将来のユーザーを保護しますが、柔軟性を制限し、オーバーヘッドを追加します。提示したような外部キー制約の場合、孤立した参照を回避する利点と比較して、オーバーヘッドは通常は小さくなります。

インデックスは、キー値と検索ポインター間のマップを提供します。 SQLユーザーは、SQLの検索ポインタを直接扱うことはありません。 （そうですね、それを可能にするSQLの方言はいくつかありますが、とにかくそれは一般に悪い考えです。）オプティマイザが検索の戦略を評価し、コストを見積もっているとき、インデックスの有無がオプティマイザに選択させる場合があります。別の上の戦略。時々、スピードアップは劇的です。インデックスの保存には少しスペースがかかり、データが変更されたときに更新に少し時間がかかります。一部のインデックスはコストに見合うものですが、そうでないものもあります。

あなたの場合、私はあなたがfk_merchant_appointmentと呼んだインデックスを省いて遊んでみます。 MySQLが代わりにapointments_indexを使用して、より少ないコストでほとんどの利点を得ることが当てはまる場合があります。確かには言えない。

3
Walter Mitty