PASSJアフタースクール

PASSJ ウェブログ参照トップ20 (2005/06/02～2005/06/16)

PASSJ ウェブログ参照トップ20 (2005/06/21～2005/07/05)

講師からの内容訂正及び補足説明を掲載いたします。

●P28 FillFactorとページ分割
（誤）FillFactorはインデックスのみ
（正）FillFactorはデータページとインデックスの両方で指定可能
注：Create Table文で[WITH FILLFACTOR = fillfactor]
というキーワードを付けて指定できます。

●P28 FillFactorとページ分割
（誤）FillFactorはインデックスのみ
（正）FillFactorはデータページとインデックスの両方で指定可能
注：
Create Table文で[WITH FILLFACTOR = fillfactor]
というキーワードを付けて指定できます。

●P36 カバリングインデックス 左の例
（質問）左の例はカバリングインデックスじゃないのでは？
（検証結果）左の例はカバリングインデックスでＯＫでした。
注：
複合キー（列A＋列B）を持つテーブルに対して、
select A,B ～where 列A = ～ならカバリングインデックスだが
select A,B ～where 列B = ～の場合は、そもそもインデックスが使えないのでカバリングインデックスにならないのではという質問でした（なるほど…）。

検証のために、左側の例のselect句の後ろに、,discount という非キー列を
追加したところ、今度は同じPKのIndex Scanながら、
今度はBookmark Lookupが挿入されました（このテーブルはヒープです）。

つまり、この左の例はインデックスが使えない検索なのに、select句の指定列を見てカバリングを使えるからということで非クラスタ化主キーのIndex Scanを選んでいると思います（賢いですね）。
ちなみに、where productid between 100 and 102の代わりに
discount = という条件で検索したところ、今度はTable Scanとなりました。

●P54 Cハッシュジョインの効果的な組み合わせ
a□ソートされた状態で結果を出力する
b□2つのテーブルを結合する有効なインデックスがない
c□親テーブルと子テーブルがともに小さい、またはインデックスで絞れる。
という設問の回答のaとbにチェックがあったので、思わずずれていると説明しましたが、cも不適切な回答でした。ここはbのみ正解とします。

注：
ハッシュ結合については、下記のように説明されています。
『結合条件に等価条件（＝）が指定され、大量のレコード、あるいは表の大部分を結合する場合に有効な結合方法。』

●テキスト外の質問 「Group By句でインデックスは有効か？」
昔の記憶を頼りに「使われないと思いますが…」と回答したのですが、念のため調べてみました。
結果：基本的には使われません。
（例）
Index Aを用意しておいて
select A,sum(B) from T Group by A
の場合はインデックスが使われず、テーブルスキャンとなる。
（注）
ただし、この場合に複合インデックスA+Bを作成しておくと、このインデックスが使われて検索が速くなる場合があります。（インデックスガバメントということですね）。上記OrderDetails1で試してみたところ、Group by OrderIDのときは使われ、Group by OrderID,ProductIDのときはテーブルスキャンになりました）。

2005/07/09(土)　【写真】　SQL Server パフォーマンスの基礎