問題タブ [indexing]

たとえば、SQL Server 2005 を使用したクエリは次のようになります。

以下を使用すると結果を返す列 SearchField を使用するように定義されたフルテキスト インデックスがあります。

# は特殊文字だと思いますが、上記のクエリで FREETEXT が正しく機能するようにするにはどうすればよいですか?

データセットのサイズが大きくなるにつれてインデックス作成が非常に重要になることを考えると、データベースに依存しないレベルでインデックス作成がどのように機能するかを誰か説明できますか?

フィールドにインデックスを付けるためのクエリについては、データベース列にインデックスを付ける方法を参照してください。

願わくば、各データベース サーバーについて回答を得ることができれば幸いです。

インデックス作成の仕組みの概要については、データベースのインデックス作成はどのように機能しますか?を参照してください。

一意のデータのみが uniqueidentifier (Guid) 列であるいくつかのテーブルがあります。GUID は非シーケンシャルであるため (クライアント側で生成されるため、newsequentialid() を使用できません)、テーブルにクラスター化されたプライマリを与えるのではなく、この ID フィールドに非プライマリの非クラスター化インデックスを作成しました。鍵。

このアプローチがパフォーマンスにどのような影響を与えるのか疑問に思っています。データベースエンジン自体がその値を使用してすばやくブックマークを使用する代わりに行を検索します。

私のデータベースは多数のサーバー間でマージ レプリケートされているため、ID の int 列を避けています。

あなたの考えは何ですか？テーブルには主キーが必要ですか? または、そのようにインデックスを付ける適切な列がない場合、クラスター化されたインデックスがなくても問題ありませんか?

私はWHERE句でこれに出くわしました：

これは次のように比較されます：

またはと：

私はいつも後者を自分で書いていましたが、明らかに他の誰かが違った考え方をしています。一方が他方よりも優れたパフォーマンスを発揮するでしょうか？私が持っていたかもしれないインデックスを使用する<>か!=、使用するという希望を打ち破るだろうと私は知っていますが、確かに上記の最初のアプローチは同じ問題を抱えていますか？

文字列に対して検索するクエリがあります。

さて、これは問題なく動作しますが、うまくスケーリングできず、最適化する必要があります。生成されたビューの作成などのオプションを見つけましたが、インデックスを使用したより簡単なソリューションを望んでいました。

DB2 を使用しており、実際には index で式を使用したいのですが、このオプションは z/OS でしか使用できないようですが、Linux を実行しています。とにかく式インデックスを試しました：

しかしもちろん、それは UPPER(名前) で詰まります。

既存のクエリを再構築して新しく生成されたビューを使用したり、既存の列を変更したり、その他のそのような侵入的な変更を行う必要がないように、この方法でインデックスまたは同様のものを作成できる別の方法はありますか?

編集：私は他のデータベースの解決策を聞くことにオープンです...それはDB2に引き継がれるかもしれません...

a もTable Scana もClustered Index Scan基本的にテーブル内のすべてのレコードをスキャンするのに、クラスター化インデックス スキャンの方が優れていると思われるのはなぜでしょうか?

例として、多くのレコードがある場合、次のパフォーマンスの違いは何ですか?:

私が見つけた情報から、どちらも同じ問題を解決します。配列の包含や共通部分（&&、@>、<@など）などのより難解な操作です。ただし、どちらを使用するか（またはどちらも使用しないか）についてのアドバイスに興味があります。PostgreSQL
のドキュメントには、これに関するいくつかの情報があります。

• GINインデックスルックアップはGiSTの約3倍高速です
• GINインデックスの構築にはGiSTの約3倍の時間がかかります
• GINインデックスの更新はGiSTの約10倍遅い
• GINインデックスはGiSTの2〜3倍です

ただし、メモリとインデックスのサイズの比率が小さくなり始めたとき（つまり、インデックスのサイズが使用可能なメモリよりもはるかに大きくなったとき）にパフォーマンスに影響があるかどうかを知りたいと思いますか？#postgresql IRCチャネルで、GINはすべてのインデックスをメモリに保持する必要があると言われました。そうしないと、Bツリーとは異なり、ディスクから読み込む部分がわからないため、効果的ではありません。特定のクエリ？質問は次のようになります：これは本当ですか（私もこれの反対を言われたので）？GiSTにも同じ制限がありますか？これらのインデックス付けアルゴリズムの1つを使用する際に注意する必要がある他の制限はありますか？

最初のアクションの 1 つとして、クエリを使用して 750K レコードを一時テーブルに入れる sproc があります。一時テーブルに入力する前にインデックスを作成すると、テーブルに入力した後にインデックスを作成する場合と比較して、項目の実行に約 2 倍の時間がかかります。(インデックスは 1 つの列の整数であり、インデックスが作成されるテーブルはそれぞれ 1 つの整数の 2 つの列だけです。)

これは私には少しずれているように思えますが、ボンネットの下で何が起こっているのかをしっかりと理解しているわけではありません。誰もこれに対する答えを持っていますか?

何百万行ものテーブルがあります。特定の列値を持つすべての行を見つける必要があります。その列はインデックスにないため、テーブル スキャンが実行されます。

しかし、列を先頭に (主キーが続く) インデックスを追加し、クエリを実行してから、インデックスを削除する方が速いでしょうか?

ユーザーが探している列を指定しているため、インデックスを永続的に追加することはできません。