インデックス指定
1. [必須] 固有のビジネス特性を持つフィールドは、結合されたフィールドであっても、一意のインデックスに組み込む必要があります。
注: 一意のインデックスが挿入速度に影響するとは考えないでください。この速度の低下は無視できますが、検索速度の向上は明らかです。また、アプリケーションが完全なチェックサム制御では、マーフィーの法則に従い、一意のインデックスがない限り、ダーティなデータが生成されることは避けられません。
を実行する場合は、関連フィールドにインデックスが必要であることを確認してください。
注: 2 つのテーブルを結合する場合でも、テーブルのインデックスと SQL のパフォーマンスに注意を払う必要があります。
実際のテキストの区別に関するインデックスの長さ。
注: インデックスの長さと識別は一対の矛盾です。一般に、文字列型データの場合、長さが 20 のインデックスの場合、識別 は次のようになります。 90 % 以上の場合は、count(distinct left(列名、インデックス長)) / count(*) の区別を使用して決定できます。
注: インデックス ファイルには B-Tree の左端のプレフィックス マッチング機能があります。左の値が不定の場合、このインデックス は使用できません。
インデックスの一部であり、file_sort の状況を回避し、クエリのパフォーマンスに影響を与えるために、インデックスの結合順序の最後に配置されます。
正の例: ここで、a =? および b =? は c 順に並べられます; インデックス: a _ b _ c
反例: インデックスに範囲検索がある場合、WHERE a >10 ORDER BY b; インデックス a _ b などのインデックスの順序付けは使用できません。
説明: 本で第 11 章のタイトルを知る必要がある場合、第 11 章に対応するページが表示されますか?ディレクトリ を参照するだけです。このディレクトリはカバー インデックスとして機能します。
良い例: 作成できるインデックスの種類: 主キー インデックス、一意インデックス、通常インデックス、およびカバー インデックスは、クエリの 効果です。追加の列が表示されます: Index を使用します。
7. [推奨] 遅延相関またはサブクエリを使用して、複数ページのシナリオを最適化します。
説明: MySQL はオフセット行をスキップしませんが、オフセット N 行を取得し、諦める前にオフセット行を返し、オフセットが次の場合は N 行を返します。特に大きい場合、効率は非常に低くなります。返されるページの総数を制御するか、特定のしきい値を超えるページ数に対して SQL を書き直す必要があります。
良い例: 取得する必要がある ID セグメントをすばやく見つけて関連付けます:
SELECT a.* FROM table 1 a, (select id from Table 1 where 条件 LIMIT 100000,20 ) b where a.id=b.id
注:
1) 単一の consts テーブルには一致する行 (主キーまたは一意のインデックス) が 1 つだけあり、データは最適化フェーズ。 2) ref は、通常のインデックス (通常のインデックス) を使用することを指します。 3) range はインデックスに対して範囲検索を実行します。反例: テーブルの結果を説明します。タイプ = インデックス、インデックス物理ファイルのフル スキャン、速度が非常に遅い、このインデックス レベル は、以前と比べてまだ低いです。範囲が広く、テーブル全体のスキャンとは異なります。 小さな魔女と大きな魔女が出会います。
良い例: a =? および b =? の列 a がほぼ一意の値に近い場合、 idx _ a のインデックスを構築するだけで済みます 。
注: 不等号と等号の判定条件が混在する場合、インデクス作成時に等号条件の列を前に置いてください。例: where a >?and b =? この場合、a の方が区別性が高い場合でも、b をインデックスの先頭に配置する必要があります。
