0

ここ数週間、クエリのパフォーマンスの問題に苦しんでいます。この時点で、JOIN タイプ、インデックス作成、最新の統計の維持などに関して、クエリからすべてを完全に絞り出しました。

少し背景。

問題のテーブルは、Record

Id INT PK
Name NVARCHAR(50)
Status INT FK 
Created DATETIME
Version NVARCHAR(10)
Data XML

いくつかのパフォーマンス ベンチマークの後、select に最後の列を含めることは、インデックス作成、結合の複雑さ、ネットワークの考慮事項などの要素を 10 倍から 20 倍もはるかに上回ることに気付きました。

次の比較は、SQL Azure に接続しているローカル開発マシン上の SSMS 間で行われました。

SELECT Id FROM Records -- ~10 secs for 300,000 rows
SELECT Id, Name, Status, Created, Version FROM Records -- ~20 sec for 300,000 rows
SELECT * FROM Records -- ~350 sec for 300,000 rows

明確にするために、私は xml 列 (XML DML または XPath クエリ) でクレイジーなことは何もしていません。選択に含める/除外するだけです。

この時点で、エンティティ、NHibernate マップ、および MVC コントローラー スタックを作成することで問題を解決したと思います。これはRecordLight、純粋にアプリでの検索とリストの目的のためです。

しかし、XML 列を含めることがクエリのパフォーマンスに悪影響を及ぼしている理由を理解したいと思います。

4

2 に答える 2

2

考慮すべき点の 1 つは、XML データのバイト単位のサイズです。

たとえば、リモート DB サーバーに接続している場合、すべてのデータをクライアントにダウンロードする必要があります (クライアントが SSMS であっても)。

たとえば、MB のデータを含む BLOB 列でも同じことがわかりました。

次のようなことをすると:

SELECT Id, LEFT(Data, 10) FROM Records

データを返すのに同じ時間が表示されますか?

于 2013-11-07T09:22:48.950 に答える
1

SQL サーバーが使用するファイルに XML データを格納する方法と関係がありますか? BLOB などの他の大きなデータ型でも同様のパフォーマンスの問題が発生しますか? 非常に大きなファイルになる可能性がある XML 列の実際のコンテンツが他のファイルに分散している場合、SQL が「つなぎ合わせる」のに時間がかかると想像できます。

于 2013-11-07T09:21:34.547 に答える