0

課題として、次のクエリと、インデックスを作成してそれらを最適化する方法が与えられました。

a)SELECT EmployeeID FROM Employee WHERE Name='John'AND Surname='Brown'

b)SELECT EmployeeID FROM Employee WHERE Salary=1300

c)SELECT EmployeeID FROM Employee WHERE Salary BETWEEN 1000 AND 1500

d)SELECT EmployeeID FROM Employee WHERE Salary+Bonus>1500

テーブル従業員から: 従業員 ID、名前、姓、給与、ボーナス

最初のものについては、a) 複合インデックスが最適であり、2 つ目はクラスター化され、3 つ目はパーティション化され、ある種のクラスター化されていると述べました (d 私は私の選択について確信が持てません。それらを確認し、私がこれに慣れていないので修正してください。PsindexesはOracleにある方がよいでしょう。事前に感謝します。

4

2 に答える 2

3

最初のもの a) 複合インデックスが最適です

どの列に？苗字＋名前、苗字＋苗字？順序は重要です。この場合、まったく問題にならない可能性がありますが、通常はアプリケーション全体を検討し、一般的にルックアップをどのように行うかを検討します。たとえば、姓のみで検索する別のクエリがある場合、このインデックスが両方のクエリで機能するように、姓の列をインデックスの最初に配置する必要があります。過剰なインデックス付けは、過少インデックス付けとほぼ同じくらいパフォーマンスに悪影響を与える可能性があります。

2 番目の方がクラスター化されている

繰り返しになりますが、インデックスを選択するときは、テーブル/アプリケーション全体を考慮する必要があります。1 つのテーブルにクラスター化インデックスを 1 つだけ持つことができます。1 つのクラスター化インデックスを EmployeeID 列に配置する必要がある可能性が高くなります。ここでそれを使用するクエリが見られなくても、それが最も一般的なニーズです。ここでは、Salary の通常のインデックスでおそらく十分です。

3番目のもののために分割された

給与の通常のインデックスで十分でしょう。データベースは最初のレコードに移動し、一致しなくなるまで「インデックスをたどる」ことができます。しかし、それはテーブルのサイズによって異なります...テーブルが巨大な場合（数千万行から数億行）、パーティション化は（通常はテーブル自体で）意味があります。何千万人もの従業員を抱える企業はあまり知りません。繰り返しますが、私たちがやりたいことの 1 つは、過剰なインデックス作成を避けることです。そのため、b) から同じインデックスを再利用することは良いことです。

(d

これはデータベース エンジンとバージョンによって異なりますが、インデックス自体がこのクエリに役立つことはほとんどありません。その理由は、式が sargable でないことが非常に多いためです。つまり、クエリ オプティマイザーは、インデックスが機能するかどうかを判断するほど賢くありません。できることは、計算列 の仮想列を作成し、その列にインデックスを配置することです。

いずれの場合も、EmployeeID 列のみを要求しているため、EmployeeID をインデックスに追加する必要がありますが、実際にはそのフィールドにインデックスを作成しません。インデックスを含む列を含めるだけです。このようにして、データベースは、テーブルに戻る必要なく、インデックスだけからクエリを完全に実行できます。列にインデックスを付けるのではなく、単に列を含める理由は、INSERT/UPDATE ステートメントのパフォーマンスを向上させ、インデックスを再構築する必要をなくすためです。

于 2013-11-10T18:34:01.030 に答える
2

d) については、関数ベースのインデックス (FBI) が適切です。

CREATE INDEX emp_i3 ON Employee (Salary+Bonus);
于 2013-11-10T23:29:33.727 に答える