5

ミニプロファイラーは次の2つの方法で使用します。

  1. ポップアップ付きの開発者マシンの場合
  2. SqlServerStorageがMSSQLに格納されているステージング/製品環境

数週間後、プロファイリングDBへの書き込みに長い時間（秒）がかかり、サイトで実際の問題が発生していることがわかりました。すべてのプロファイラーテーブルを切り捨てると、問題が解決します。

SqlServerStorageコードを見ると、インサートはそのIDの行がまだ存在していないことを確認するためのチェックも行っているようです。これは、DBに依存しないコードを保証するためですか？これは、行数が増えるにつれて大きなペナルティをもたらすようです。

パフォーマンスプロファイラーからパフォーマンスペナルティを削除するにはどうすればよいですか？他の誰かがこの減速を経験していますか？それとも私たちが間違っていることですか？

助けやアドバイスをお願いします。

4

1 に答える 1

6

うーん、デフォルトでクラスター化されることを忘れたときに、そのMiniProfilersテーブルがどのように作成されたかに大きな間違いを犯したようprimary keyです...そしてクラスター化インデックスはGUID列であり、非常に大きな違いです。

データはクラスター化インデックスと同じ順序でディスクに物理的に格納されるため（実際、テーブルはクラスター化インデックスであると言えます）、SQLServerは新しく挿入されたすべての行をその物理的な順序で保持する必要があります。これは、本質的に乱数を使用している場合、ソートを維持するための悪夢になります。

修正は、他のすべてのテーブルと同じように、自動増加intを追加し、主キーをそれに切り替えることです（なぜこれを見落としたのか、覚えていません...ここでStackOverflowでこのストレージプロバイダーを使用していませんまたは、この問題はずっと前に発見されていたでしょう）。

テーブル作成スクリプトを更新し、現在のテーブルを少しで移行するための何かを提供します。

編集

これをもう一度見てみると、メインMiniProfilersテーブルは単なるヒープである可能性があります。つまり、クラスター化されたインデックスはありません。行へのすべてのアクセスはそのGUIDID列によるため、物理的な順序付けは役に立ちません。

MiniProfiler sqlテーブルを再作成したくない場合は、次のスクリプトを使用して、主キーを非クラスター化できます。

-- first remove the clustered index from the primary key
declare @clusteredIndex varchar(50);

select  @clusteredIndex = name
from    sys.indexes
where   type_desc = 'CLUSTERED'
        and object_name(object_id) = 'MiniProfilers';

exec ('alter table MiniProfilers drop constraint ' + @clusteredIndex);

-- and then make it non-clustered
alter table MiniProfilers add constraint 
  PK_MiniProfilers primary key nonclustered (Id);

別の編集

了解しました。作成スクリプトを更新し、ほとんどのクエリのインデックスを追加しました。GitHubのコードをご覧ください。

既存のテーブルをすべて削除して、更新されたスクリプトを再実行することを強くお勧めします。

于 2012-12-05T01:50:58.780 に答える