良いインデックスをデザインしたい、あなたが最初のデータベース・サーバにSQLステートメントの過程を理解する必要があり、この記事では説明のデータベースインデックスの設計と最適化、いくつかの最適化は、インデックスのために非常に重要な概念です。
述語
述語は、条件式です。一の以上の述語により、SQL文のwhere句。
WHERE SEX = 'M'
AND
（WHIGHT> 90
OR
HEIGHT> 190）
上記の3つの簡単なWHERE句述語：
- SEX = 'M'
- WRIGHT> 90
- HEIGHT> 190
また、2つの述語の組み合わせとみなすことができます。
- WEIGHT> 90 OR HEIGHT> 190
- SEX = 'M' AND（重量> 90 OR HEIGHT> 190）
オプティマイザのアクセス・パス
リレーショナルデータベースの利点の一つは、ユーザーがデータの関係へのアクセスを持っていないということです。DBMSの構成要素であるアクセス経路、すなわち、オプティマイザが決定します。SQLオプティマイザは、プロセスの心臓部です。
ここでの例では、単純なMySQLのMySQLサーバの論理的な構造を表示します
図では、オプティマイザの位置を確認することができます。
実際に実行されるSQLステートメントの前に、オプティマイザは、第1のデータにアクセスする方法を決定する必要があります。などのMySQLは、クエリを解析し、解析ツリーを作成し、テーブルの読み取り順序を決定するために、右のインデックスを選択するための決定を含め、様々な最適化に供することができます。
述語式は、インデックスの設計のための主要な出発点です。インデックスは、すべての述語表現にSELECTクエリを満たすためにした場合、オプティマイザは効率的なアクセスパスを確立する可能性があります。
インデックス一致列と
インデクシングB +ツリーの形で編成した場合、述語式がある場合は、WHERE A > 100 AND A < 110範囲のリーフノードへの問合せは、最終的には下図になります。
したがって、アクセスパスのコストは、範囲を決定述語表現であるインデックス紙の厚さに大きく依存します。インデックス、スキャンするより多くのインデックスページ、より多くの治療を必要とするインデックスレコードが、最大のコストは、テーブル上の同期読み取り操作から増加させ、より厚い、各ページの表には、I / O読みます操作は10msのかかる場合があります。したがって、インデックスシートが比較的狭いですが、それは、同期テーブルの読み取りを削減します。
インデックスフィルタ及び濾過カラム
すべてのインデックス列は、インデックスのサイズを定義できるわけではありません。時々、カラムは、両方のWHERE句内に存在してもよく、それはまた、インデックスに存在するが、カラムは、例えば、指標の定義に参加することはできません。テーブル上の関節指数（A、B、C、D）、次のSQL文：
ここで、A = A
AND
B>：B
AND
C = C
私たちは、WHERE句の述語は、インデックスのサイズを決定するかどうかを決定する必要があります。
- まず、我々はWHERE句で見て、列には、少なくとも持っているシンプルな十分な述語が対応しますか？もしそうなら、この列には、列を一致させることです。そうでない場合には、背面行と列のインデックスは、比類のない列です。
- 述語は、述語の範囲であれば、残りの非マッチング・インデックス・カラムはカラムです。
- 述語は、列としてフィルタ次いで、それに対応している場合、最後の一致列の後に列のインデックスのために、十分に単純を有します。この方法によれば、我々はまた、列と一致、列Bは、範囲述部であり、輪郭は、このように、カラムAに一致する、カラムに十分に単純な述語である述語を、表示決定することができます。C列B指数の背面は（指標が狭くなることはできませ）定義することができないが、それはまだインデックスのフィルタリングプロセスに参加することができます。すなわち、我々は、列Aと列B、C及びカラムを通してインデックス紙のサイズを定義することではないが、テーブルにアクセスする前に、フィルタは、まだ列Cによって記録することができ、不要なアクセステーブルを低減することができます。列Cが所属濾過カラムを、それは同様に重要と列B列であります
要約：
WHERE句は、索引スキャンを定義するために、上記の二つの列、列Aおよび列Bに一致します。フィルターカラムとしてカラムに加えて、C。だから、同時にラインが3つの述語を満たす場合にのみ、テーブル内のデータにアクセスします。
述語式は等価述語列Bの場合、3つの列が一致列として使用することができます。
カラムのキャンセル述語表現は、インデックス断片をインデックス全体のサイズである場合、列BおよびCは、単にだけフィルタリングするために使用されます。
フィルタ係数
フィルタ述語の選択を説明行因子の数の比は、すなわち、主にカラム値の分布に依存する、占有述語条件テーブルを満足します。
フィルタ係数は次のように計算されます。
结果集数量/表行的数量
女性ユーザーを追加する場合たとえば、私たちはユーザーSEXのリストにこのフィールドを持って、SEX =「F」のフィルタ係数が大きくなります。
表中の男性の70％は、その後、SEX =「M」フィルタ係数が70％であれば、SEX =「F」フィルタ係数は30％で、70％の最悪の場合SEXカラム濾過率、平均フィルタ係数50％。
いずれかの雌比一方にオス場合、SEX最悪ケースと平均フィルタ係数に記載されているフィルタ係数は50％です。
ワーストケースおよび最悪関連入力は、この状態で、入力は、特定のインデックスに基づいて、クエリが最大を消費するので、我々は、最悪の場合のフィルタ係数は平均フィルタ係数よりも重要な指標の適合性を評価します時間。
述語のためのコンビネーションフィルタ係数
その後、我々はどのようにそれのトリオ述語式フィルタ係数を計算するには？
述語間の列場合は無関係な、次いで述語述語のフィルタ係数の組み合わせは、単一のフィルタ係数から導出することができます。
非関連互いに独立して2つの述部の平均値は、彼の都市の価値がなければならないので、例えば、私たちは「州」と「街」の2つのフィールドがあり、ユーザーテーブルを持っており、この2つの述語に関連していることどこの街を保存します。CITYやBD（誕生日）は、述語とは関係ありません。
そのような組み合わせ述語CITY = :CITY AND BD = :BD述語に等しいフィルタ係数CITY = :CITYと述語のBD = :BDフィルタの乗算係数。
列CITY 2,000の異なる値、カラムBD 2,700の異なる値場合、組み合わせ述語フィルタ係数は、次のとおり1/2000*1/2700。次いで、列の組み合わせ[CITY、BD] 540万個の異なる値の合計。
リストの関連性について、値がこれよりもはるかに小さくなります。
私たちは、フィルタ係数を評価するため、全体として見述語のSQL文を組み合わせる必要が索引構造を設計します。
インデックスフィルタの設計上の要因
明らかに、影響のアクセスパスの性能の指標をスキャンする必要の大きさが必要不可欠です。フィルタ係数、小さい方が指標のうち、スクリーニングより小さく、より多くの場合、それは、テーブルへのアクセスを意味します。
表が共同インデックスを持っていると仮定 (MAKE, MODEL, YEAR)
SQL文の場合：
SELECT PRICE、COLOR、DEALERNO
CAR FROM
WHERE MAKEは=：MAKE
AND
MODEL =：MODELの
ORDER BY PRICE
製造元とモデルの列が一致しています。組み合わせ述語フィルタ係数は0.1％であった場合には、インデックスのサイズは、0.1％の全体のインデックスにアクセスする必要があります。
インデックスが良くないことを次のSQL文の場合：
SELECT PRICE, COLOR, DEALERNO
FROM AUTO
WHERE MAKE = :MAKE
AND
YEAR = :YEAR
由于联合索引的最左匹配原则，匹配列只有MAKE。过滤因子为1%，索引片比较大。
sql语句：
SELECT LNAME, FNAME, CNO
FROM CUST
WHERE SEX='M'
AND
(WEIGHT > 90
OR
HEIGHT > 190)
ORDER BY LNAME, FNAME
这个SQL语句查找身材高大有一定要求的男性，此时匹配谓词只有一个SEX，过滤因子正常情况下为50%，如果表有100万行记录，那么索引片就有50万行，这就是相当厚的索引片了。
练习
思考一下为以下两个SQL语句设计最佳的索引
SELECT LNAME, FNAME, CNO
FROM CUST
WHERE SEX = 'M'
AND
HEIGHT > 190
ORDER BY LNAME, FNAME
SELECT LNAME, FNAME, CNO
FROM CUST
WHERE SEX = 'M'
AND
(WHIGHT > 90
OR
HEIGHT > 190)
ORDER BY LNAME, FNAME