SQL Server インデックス 重複可/不可
- このフォーラムに新しいトピックを立てることはできません
- このフォーラムではゲスト投稿が禁止されています
nkmt
投稿数: 1668
![長老 長老](../../uploads/rank3dbf8eb1a72e7.gif)
質問ではないのですが長文失礼します。
Pervasiveの時はインデックス重複不可は1個だけにして、それ以外のインデックスは、ユニーク項目を含んでいても重複可にしておりました。
SQL Serverでもインデックスで同じように定義してみました。
テーブルコントロールを使った一覧表示で
重複可インデックスに対し、位置付け照会を行うと
極端に遅かったので、位置付け照会を行うインデックスは
ユニーク項目を含めるようにして、重複不可にした所、
速度も改善しました。
以前どこかでSQL系は位置付けよりも、範囲絞りがいい
というのを聞いた事もあります。
今後、いろんなインデックスを重複可にしていこうと
考えておりますが、変でしょうか?
よろしければご意見お聞かせ下さい。
よろしくお願い申し上げます。
Pervasiveの時はインデックス重複不可は1個だけにして、それ以外のインデックスは、ユニーク項目を含んでいても重複可にしておりました。
SQL Serverでもインデックスで同じように定義してみました。
テーブルコントロールを使った一覧表示で
重複可インデックスに対し、位置付け照会を行うと
極端に遅かったので、位置付け照会を行うインデックスは
ユニーク項目を含めるようにして、重複不可にした所、
速度も改善しました。
以前どこかでSQL系は位置付けよりも、範囲絞りがいい
というのを聞いた事もあります。
今後、いろんなインデックスを重複可にしていこうと
考えておりますが、変でしょうか?
よろしければご意見お聞かせ下さい。
よろしくお願い申し上げます。
投票数:0
平均点:0.00
pu_mahalo
居住地: 大阪
投稿数: 775
![長老 長老](../../uploads/rank3dbf8eb1a72e7.gif)
こんにちは Puです
早くなるならないは オプティマイザーによりますので
オプティマイザー君が どのような実行プランで実行するのか
(クラスタ化indexを上手に使用してるのか 通常のindexの使用なのか はたまは シーケンシャルで読んでいるのか など)を
グラフィカルに表示して 分析するのが 一般的です
MagicがどのようなSQL文をだしてるか 調べて
studioのクエリ実行の画面で 右クリック==>
推定実行プランの表示
でプラン(どのような動作)か表示できますので
チューニングのヒントになるかと
でわ〜でわ〜
早くなるならないは オプティマイザーによりますので
オプティマイザー君が どのような実行プランで実行するのか
(クラスタ化indexを上手に使用してるのか 通常のindexの使用なのか はたまは シーケンシャルで読んでいるのか など)を
グラフィカルに表示して 分析するのが 一般的です
MagicがどのようなSQL文をだしてるか 調べて
studioのクエリ実行の画面で 右クリック==>
推定実行プランの表示
でプラン(どのような動作)か表示できますので
チューニングのヒントになるかと
でわ〜でわ〜
投票数:1
平均点:10.00
kitabayashi
投稿数: 39
![半人前 半人前](../../uploads/rank3dbf8e94a6f72.gif)
データの並び順のためにインデックスを作成しているのであれば、
仮想キーを使用したインデックスを使用してみてはどうでしょうか。
データリポジトリのインデックス特性で設定できます。
位置付けにユニーク項目を設定していれば、
index seekでselectしてくれると思われます。
仮想キーは、設定したカラムがorder byに追加されるだけで、
実インデックスを作成しないので、更新時の速度も上がると思います。
仮想キーを使用したインデックスを使用してみてはどうでしょうか。
データリポジトリのインデックス特性で設定できます。
位置付けにユニーク項目を設定していれば、
index seekでselectしてくれると思われます。
仮想キーは、設定したカラムがorder byに追加されるだけで、
実インデックスを作成しないので、更新時の速度も上がると思います。
投票数:1
平均点:10.00
nkmt
投稿数: 1668
![長老 長老](../../uploads/rank3dbf8eb1a72e7.gif)
Puさん kitabayashiさん レス有難うございます。
大変参考になります。
Pervasiveの時は
範囲絞り条件や並べ替えに準じたインデックス
を作らないと速度に困る事が多かったように思います。
メインファイルのインデックス指定を
間違えると折角のインデックスも使わずに劇遅になったり。
1本のデータにインデックスを9本とか作る事も
珍しくありませんでした。
SQL ServerだとSQL Serverが解釈して最適なインデックス
で読んでくれるのですかね。
仮想キーってMagicがSQL Serverにorder byを依頼する
面白い機能と言えますか???^^;
範囲絞りに実キーを用意し、
並べ替え用は仮想キーにするという事でいいのでしょうね。
ちょっと理解出来てきたような気がします。
大変参考になります。
Pervasiveの時は
範囲絞り条件や並べ替えに準じたインデックス
を作らないと速度に困る事が多かったように思います。
メインファイルのインデックス指定を
間違えると折角のインデックスも使わずに劇遅になったり。
1本のデータにインデックスを9本とか作る事も
珍しくありませんでした。
SQL ServerだとSQL Serverが解釈して最適なインデックス
で読んでくれるのですかね。
仮想キーってMagicがSQL Serverにorder byを依頼する
面白い機能と言えますか???^^;
範囲絞りに実キーを用意し、
並べ替え用は仮想キーにするという事でいいのでしょうね。
ちょっと理解出来てきたような気がします。
投票数:0
平均点:0.00
Tanda
投稿数: 2151
![長老 長老](../../uploads/rank3dbf8eb1a72e7.gif)
nkmt さん、こんにちは。
SQL の場合は、むやみにインデックス化するよりも、非インデックス
のまま、LIKE 関数(LIKE コマンド)を使ったほうが効率がいい場合
もありますよ。
SQL の LIKE コマンドは信じられないくらい速い場合があります。
この世のものとも思えないくらいの結果が出る場合がありますよ。
SQL の場合は、むやみにインデックス化するよりも、非インデックス
のまま、LIKE 関数(LIKE コマンド)を使ったほうが効率がいい場合
もありますよ。
SQL の LIKE コマンドは信じられないくらい速い場合があります。
この世のものとも思えないくらいの結果が出る場合がありますよ。
投票数:1
平均点:10.00