1

SQL Serverデータベースがあり、テーブルに1500000行があります...次の手順のデータ実行時間が非常に長いためです

テーブル - - -

CREATE TABLE [dbo].[MyTable](
[Id] [bigint] IDENTITY(1,1) NOT NULL,
[Link] [text] NULL,
[Title] [text] NULL,
[Duration] [text] NULL,
[Image] [text] NULL,
[Embbed] [text] NULL,
[Keywords] [text] NULL,
[Category] [text] NULL,
PRIMARY KEY CLUSTERED 
(
[Id] ASC
)
WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

手順 - - - 

ALTER PROCEDURE [dbo].[Search]
 @SearchQuery varchar(1000),
 @Id bigint
 As
BEGIN
  Select top 100 * from MyTable
  where Id > @Id and Title like '%'+@SearchQuery+'%'

1500000行のテーブルでSQLクエリの実行時間を最小限に抑える方法を教えてください。

4

6 に答える 6

4

次の方法でテーブルスキャンを強制します。

'％' + @ SearchQuery +'％'のようなタイトル

実際にはありません-あなたは間違いなくタイトルのインデックスの不使用を強制します。インデックスが「左から右」に移動すると、「中間のあるポイント」クエリがインデックスの使用をオフにします。

IDが検索に多くを残している場合、特にそれを不適切に遅いハードウェアと組み合わせると、そこに行きます（結局、150万は小さなデータです）。

LIKEステートメントの最初の「％」を削除する（インデックスを使用できるようにする）か、全文検索を使用します。これにより、インデックス内の単語が既に分割されますが、それでも最初の「％」を削除することをお勧めします。 ％"。

于 2012-12-10T08:37:13.393 に答える
3

問題はLIKE節にありWHEREます。フィールド内の任意の位置でテキストを検索しているため、Title列に存在する可能性のあるインデックスが使用されていない可能性があります。

LIKEフィールド（）の中央にある用語を使用して検索する必要がある限りLIKE '%...'、クエリランタイムを最適化する可能性はおそらくありません。

（クエリエンジンはそれ自体を実行するのに十分スマートである必要がありますが）実行できることは次のとおりです。

ID > @ID一時テーブルへのエントリを選択し、ステートメントTOP 100を使用してそのテーブルからを選択します。LIKE

于 2012-12-10T08:29:27.240 に答える
0

あなたのテーブル定義を投稿してください、それは私たちがあなたを助けるのを助けるでしょう。ただし、確認できることがいくつかあります。

  • primary keyテーブルにとが含まれていることを確認してくださいclustered index。それらが存在する限り、それらが何に定義されているかはほとんど問題ではありません。Idただし、他の情報がない場合は、それらを定義することをお勧めします。

  • 本当にテーブルからすべての列を返す必要がありますか？列がたくさんあり、必要な列が少ない場合は、それらを明示的に指定します。これにより、結果セットのサイズが縮小されます。

  • ユーザーがで包含検索を実行することが本当に必要かどうかを尋ねますTitle。代わりに検索から始める、つまり最初の検索を削除することで逃げることができます'%'か？それができる場合、TitleフィルターはSARGableになります。つまり、クエリオプティマイザーはTitle、テーブルスキャンを実行する代わりに、列のインデックスを使用します。インデックスTitleはありますか？

アップデート：

テーブル定義を見て、Titleタイプが。であることに気付きましたtext。すべてのデータはテーブル行の外部に格納され、個別にフェッチする必要があるため、これはテーブルスキャンでの検索に非常に時間がかかります。タイプに変更することで、これを高速化できますvarchar。に相当する現代のtextはvarchar(max)ですので、最初にそれを試してください。ただし、これはタイトルなので、列に2GB相当の文字が本当に必要ですか？ほとんどのタイトルはせいぜい100文字以内です。すべてのタイトルの長さを測定して、列の長さをより合理的な長さに短縮できるかどうかを確認してください。

実際、すべての列の名前を見ると、の使用を正当化するものは何textも見つかりません。私がURLだと思っているものでさえLink、それ以上は必要ありませんvarchar(1023)。

于 2012-12-10T08:36:53.797 に答える
0

フィールドタイプとしてのVARCHAR(MAX)代わりに使用します。TEXT

TEXTフィールドはテーブルの残りの部分とは別の場所に格納されますが、VARCHAR（MAX）フィールドは行データとともに格納されるため、このタイプのフィールドにフルテキストインデックスを適用することができます。

于 2012-12-10T11:29:15.503 に答える
0

これはまだ開いていますか？テキストフィールドをvarcharに変更し、set rowcountステートメントを追加した後、主要なワイルドカード機能を保持する必要がある場合は、SQLでできることをすべて実行しました。私はこの種のことをパフォーマンスの問題なしに定期的に行っているので、次のステップはハードウェアのアップグレードです。

于 2013-06-06T19:38:29.557 に答える
-1

他の人が言ったように、私はあなたのLIKEステートメントをテーブルのフルスキャンを引き起こすと言ったように変更します。CharIndexLIKE

http://msdn.microsoft.com/en-us/library/ms186323.aspxは、CHARINDEX

于 2012-12-10T10:27:38.640 に答える