SQL Server インデックス 重複可／不可

質問ではないのですが長文失礼します。

Pervasiveの時はインデックス重複不可は１個だけにして、それ以外のインデックスは、ユニーク項目を含んでいても重複可にしておりました。

SQL Serverでもインデックスで同じように定義してみました。


テーブルコントロールを使った一覧表示で
重複可インデックスに対し、位置付け照会を行うと
極端に遅かったので、位置付け照会を行うインデックスは
ユニーク項目を含めるようにして、重複不可にした所、
速度も改善しました。

以前どこかでSQL系は位置付けよりも、範囲絞りがいい
というのを聞いた事もあります。

今後、いろんなインデックスを重複可にしていこうと
考えておりますが、変でしょうか？

よろしければご意見お聞かせ下さい。
よろしくお願い申し上げます。

こんにちは　Ｐｕです

早くなるならないは　オプティマイザーによりますので
オプティマイザー君が　どのような実行プランで実行するのか
（クラスタ化indexを上手に使用してるのか　通常のindexの使用なのか　はたまは　シーケンシャルで読んでいるのか　など）を
グラフィカルに表示して　分析するのが　一般的です

MagicがどのようなSQL文をだしてるか　調べて
studioのクエリ実行の画面で　右クリック==>
推定実行プランの表示
でプラン（どのような動作）か表示できますので
チューニングのヒントになるかと
でわ〜でわ〜

データの並び順のためにインデックスを作成しているのであれば、
仮想キーを使用したインデックスを使用してみてはどうでしょうか。

データリポジトリのインデックス特性で設定できます。

位置付けにユニーク項目を設定していれば、
index seekでselectしてくれると思われます。

仮想キーは、設定したカラムがorder byに追加されるだけで、
実インデックスを作成しないので、更新時の速度も上がると思います。

Puさん kitabayashiさん レス有難うございます。
大変参考になります。

Pervasiveの時は
範囲絞り条件や並べ替えに準じたインデックス
を作らないと速度に困る事が多かったように思います。

メインファイルのインデックス指定を
間違えると折角のインデックスも使わずに劇遅になったり。

１本のデータにインデックスを9本とか作る事も
珍しくありませんでした。

SQL ServerだとSQL Serverが解釈して最適なインデックス
で読んでくれるのですかね。

仮想キーってMagicがSQL Serverにorder byを依頼する
面白い機能と言えますか？？？^^;


範囲絞りに実キーを用意し、
並べ替え用は仮想キーにするという事でいいのでしょうね。

ちょっと理解出来てきたような気がします。

nkmt さん、こんにちは。

SQL の場合は、むやみにインデックス化するよりも、非インデックス
のまま、LIKE 関数（LIKE コマンド）を使ったほうが効率がいい場合
もありますよ。

SQL の LIKE コマンドは信じられないくらい速い場合があります。
この世のものとも思えないくらいの結果が出る場合がありますよ。