外部キーを追加するすべての列にインデックスを付けます

Question

現在、外部キーについて学習しており、データの整合性を保証するために、自分のアプリケーションでできるだけ多くのキーを追加しようとしています。私はMySQLのINNODBを使用しています。

私clicksテーブルは、構造体のような何か...約12 _id列に対する

id, timestamp, link_id, user_id, ip_id, user_agent_id, ...などがあります。

明らかにこれらのすべてが他のテーブルを指しているので、私はそれらに外部キーを追加する必要がありますか？ MySQLはすべての外部キーに対して自動的にインデックスを作成しています。したがって、基本的に私はすべてのカラムにインデックスを持っていますか？これは私が欲しいものですか？

FYI - この表は基本的に私の一番大きなテーブルです。私の研究では、基本的に、パフォーマンスの犠牲を犠牲にしていると言われていますが、パフォーマンスの低下がどれほど厳しいかは示唆されていません。

Answer 1

このような行を挿入する直前に、IDを取得するために12個の挿入または検索を行いましたか？次に、INSERTを実行するときに、12のチェックを行い、それらのIDのすべてが一致することを確認します。なぜ迷惑だ？コードでそれらを確認しただけです。

確かに、開発中のFKを持ってください。しかし、プロダクションでは、すべてのコーディングミスを排除したはずなので、FKは無駄です。

関連するヒント - 一度にすべての作業を行わないでください。生の（まだ正規化されていない）データをステージングテーブルに入れます。新しい正規化キーを追加して_idを取得するには、バルク操作を定期的に実行します。次にを '実際の'テーブルに移動します。これには、テーブル上の読み取りに対する干渉を減らすという追加の利点があります。 1秒あたり100インサートを超えることが予想される場合は、さらに検討してみましょう。

Answer 2

一般的な答えは、データ項目が重要であると考えて、可能な値のルックアップテーブルを作成したとしたら、孤立したレコードを取得しないように外部キー関係を作成する必要があります。

ただし、クリックテーブル内のすべてのデータ項目（フィールド）にルックアップテーブルが必要かどうか再考する必要があります。たとえば、ip_idフィールドはおそらくIPアドレスを表します。 IPアドレスはクリックテーブルに直接格納するだけで、ルックアップテーブルは実際には必要ありません.IPアドレスの範囲が広く、IPアドレスが一意であるためです。

フィールドの再評価に基づいて、関連するテーブルの数、つまり外部キーとインデックスの数を減らすことができます。ここで

Answer 3

が考慮すべき3つのことです：

1. このテーブル上の書き込みに読み込むの比率は何ですか？もしあなたが書くよりはるかに頻繁に読んでいるのであれば、より多くのインデックスが良いかもしれませんが、そうでなければ、それらのインデックスを維持するコストは負担しにくくなります。
2. 外部キーのいくつかはあまり選択的ではありませんか？ gender_id列にインデックスがある場合は、おそらくスペースの無駄です。私の一般的なルールは、列を含まないインデックスは、（値が一意でない限り）約1000個の別個の値を持つ必要があり、そこから微調整する必要があるということです。
3. 外部キーがクエリのフィルタとして使用されることはほとんどありませんか？ last_modified_user_idフィールドがあるが、特定のユーザーによって最後に変更されたアイテムのリストを返すクエリがない場合、そのフィールドのインデックスはあまり有用ではありません。

インデックスについての知識は、ほんの僅かです。私はお勧めしますhttp://use-the-index-luke.com