これはかなり長い間私の心にありました。非常に読み取り負荷の高いデータベースがあり、特定の 1 つのテーブルのほぼすべての列にインデックスがあります。これらのインデックスは無駄ではなく、既存のインデックスを使用するようにクエリを調整して、新しいインデックスが不要になるように最善を尽くしました。
それでも、クエリとインデックスを最適化した後、テーブルにそれらがたくさんあるようです。
インデックスを削減するために私が思いついた唯一の実際の解決策は、情報の一部 (多くは重複または類似) を独自のインデックスを持つ異なるテーブルに格納することです。
複数のインデックスを持つ1 つのテーブルではなく、いくつかのインデックスを持つ複数のテーブルが必要です。
問題は、私が学んだ 2 つの mysql プラクティスが競合していることです。
- 重複した情報を複数のテーブルに格納しないでください。データは一度だけ保存するとクリーンで効率的です。
- テーブルのすべての列にインデックスを付けるべきではありません。これは、mysql エンジンが各インデックスをチェックして使用できるかどうかを確認する必要があるため、実際にはクエリの速度が低下します。
上記の 2 つの項目は「公式」ではなく、過去に学んだことを引用しているだけです。
では、どの「ベスト プラクティス」が「より良い」プラクティスでしょうか? どちらがより重要ですか?
編集:例が私の言いたいことを示すのに役立つことを願っています。
Bob (user_id 10) と jack (user_id 5) という 2 人のユーザーがいるとします。ユーザーは、支払いテーブルから「稼いだ」金額を知りたいと考えています。
ボブの場合:SELECT SUM(amount) FROM payments WHERE user_id=10
このクエリはすべてのユーザーに対して何度も実行されるため、user_id列にインデックスが作成され、このクエリが非常に高速になります。
また、ユーザーは紹介収入の 5% を獲得します。ジャックはボブの紹介者なので、彼は支払いの 5% を受け取ります。
ボブの紹介収益:SELECT (SUM(amount)*.05) FROM payments WHERE referral_id=10
注: 複数のユーザーがボブの紹介者になる可能性があるため、このuser_id列は使用できません。
したがって、2 つのオプションがあります。別のインデックスを追加するか、referral_id別のテーブル「referral_payments」を作成して、同様の情報を別の行に格納します。このテーブルにはインデックスがありますreferral_id.
これを 10 倍すると、新しいテーブルの作成を開始するか、既にかなりの数のテーブルがあるにもかかわらず新しいインデックスを作成し続ける必要がある状況になります。