3

最近、テーブルの列定義の 1 つをnvarcharfromに変換する必要がありましたvarchar。それ以来、テーブルを介したデータの検索が遅くなったように感じます。

テーブルには4200000以上の行があり、成長しています。

私の Web アプリは現在、ストアド プロシージャを使用してデータベースからデータを取得していません。ストアド プロシージャを使用すると、検索のパフォーマンスが少し向上しますか?

または、改善のために他にアドバイスはありますか？

現在使用されているクエリは次のとおりです。

SELECT TOP 100 id, callerID, dateTime, activity, senderNum, msgSent, smsgRespond, msgIn 
FROM tbl_activitylog 
WHERE callerID = @callerID 
ORDER BY id DESC

列msgSentは nvarchar に変換されたものです。

以下はテーブル構造です。

id (int, Primary Key, Auto Increment)  
callerID (bigint)  
dateTime (datetime)  
activity (varchar(50)  
senderNum (int)  
msgSent (nvarchar(160))  
smsgRespond (varchar(50))  
msgIn (varchar(160))

インデックス部分がわかりません。

4

3 に答える 3

4

インデックスの部分については知らなかったので、データベースにインデックスを作成していなかったと思います。

データベースのパフォーマンスを扱う際に最も重要なことはINDEXESです。

に索引を追加します(callerID, id DESC)。

あなたのクエリは、はるかに高速になります。

SSMS でクエリを実行し、[推定クエリ プラン] を押すこともできます。ほとんどの場合、インデックスが見つからないという警告が表示されます。この警告を実際にコピーして貼り付けて、実行するだけです。変更する必要があるのは、インデックスの名前だけです。

于 2012-05-12T07:41:51.073 に答える
1

に対するインデックスがvarcharあり、クエリにが含まれている場合Nvarhchar、そのようなインデックスは無視されます。使用するすべてのタイプを同期し（どこでも同じ）、インデックスを再構築する必要があります。例：

ALTER INDEX IX_msgSent ON tbl_activitylog REBUILD
于 2012-05-12T08:05:01.090 に答える
1

編集:クエリをストアド プロシージャに入れても、自動的にパフォーマンスが向上するわけではありません。したがって、「単純な SELECT ステートメント」で必要なすべてのデータを取得できる場合は、次のようにします。

ただし、データベースを確認し、最終的に修復する必要があります。

DBCC CHECKDB('<db_name>') -- check the db for error
DBCC UPDATEUSAGE('<db_name>') -- fix errors

関連するインデックスを作成することも重要です。

編集: クエリを投稿した後: CalledId にインデックスを追加します。

SQL SELECTS を確認し、WHERE ステートメントにある列を確認し、それらのインデックスを追加します。これでかなり改善されるはずです！

于 2012-05-12T07:03:03.790 に答える