SQLサーバー、インデックス
- このフォーラムに新しいトピックを立てることはできません
- このフォーラムではゲスト投稿が禁止されています
Tanda
投稿数: 2151
投稿数: 2151
ISHIJIMAさん、
同感です。SQLの検索はインデックスなしでも人間業とは思えない
くらい（笑）速いですから、利用価値はありますね。
Googleの検索にも感心しますが、人間工夫次第でいろんなことが
可能になりますね。
同感です。SQLの検索はインデックスなしでも人間業とは思えない
くらい（笑）速いですから、利用価値はありますね。
Googleの検索にも感心しますが、人間工夫次第でいろんなことが
可能になりますね。
投票数:0
平均点:0.00
ISHIJIMA
居住地: 静岡県
投稿数: 1827
居住地: 静岡県
投稿数: 1827
ＳＱＬサーバーの場合インデックスを作成してもあまり変わらないことが多くメモリ等を追加した方が効果的な場合が多かったので、私はインデックスはほとんど作成していません。
投票数:1
平均点:10.00
nkmt
投稿数: 1668
投稿数: 1668
こんにちは。いつもありがとうございます。
オプティマイザー、実行プラン という部分が意味がわかりません。
Magicだけやってれば知らない人も多いんですかね。
今回の場合、インデックス２本だけなので、更新時の速度も問題無いでしょうから作ろうと思います。
そして集計するMagicのプログラムもSQLサーバーの場合、意味が有るのかわかりませんが、メインソースのインデックスも式で切り替えたいと思います。
オプティマイザー、実行プラン という部分が意味がわかりません。
Magicだけやってれば知らない人も多いんですかね。
今回の場合、インデックス２本だけなので、更新時の速度も問題無いでしょうから作ろうと思います。
そして集計するMagicのプログラムもSQLサーバーの場合、意味が有るのかわかりませんが、メインソースのインデックスも式で切り替えたいと思います。
投票数:0
平均点:0.00
pu_mahalo
居住地: 大阪
投稿数: 775
居住地: 大阪
投稿数: 775
こんにちは Ｐｕです
SQLserverはデータの量と過去に検索した時の実行履歴等で
判断しますので
どちらが良いと言うのはないです
読み込みのパフォーマンスだけを考えれば両方indexを作成して
オプティマオザーに任せる
それでも遅い場合は実行プランを調査し
対策すると言う流れでしょうか
結論から言うと indexは両方作る かな
でわ〜でわ〜
SQLserverはデータの量と過去に検索した時の実行履歴等で
判断しますので
どちらが良いと言うのはないです
読み込みのパフォーマンスだけを考えれば両方indexを作成して
オプティマオザーに任せる
それでも遅い場合は実行プランを調査し
対策すると言う流れでしょうか
結論から言うと indexは両方作る かな
でわ〜でわ〜
投票数:0
平均点:0.00
nkmt
投稿数: 1668
投稿数: 1668
SQLサーバーで、得意先コードと年月でユニークになる実績データを作るとします。
得意先１件で絞って集計する事もあれば
年月指定で縛って集計する事も有ります。
この場合、インデックスは
得意先＋年月 と
年月＋得意先 の両方作った方がパフォーマンスはいいのでしょうか？
Pervasiveの時は、間違いなく両方作成しておりました。
データを沢山作成して速度の検証すればいいんでしょうけど。
得意先１件で絞って集計する事もあれば
年月指定で縛って集計する事も有ります。
この場合、インデックスは
得意先＋年月 と
年月＋得意先 の両方作った方がパフォーマンスはいいのでしょうか？
Pervasiveの時は、間違いなく両方作成しておりました。
データを沢山作成して速度の検証すればいいんでしょうけど。
投票数:0
平均点:0.00