この質問は理論的かつ実用的です。クエリの最適化に役立つリソースを示す結果があれば幸いです。
SQLXMLフィールドに格納された大量のデータを格納する大規模なSQLデータベースがあります。XMLを直接クエリするのは十分な速度ではありません。
SQLXMLの最適化に関するMSDNの記事（ http://msdn.microsoft.com/en-us/library/aa902661(SQL.80).aspx ）をいくつか見てきましたが、検索可能なxmlフィールドのインデックス作成が増えることを認識しています。検索速度。
この環境または一般的に、データベースを最適化するために特に役立つ追加のリソースを誰かが推奨できますか？いつものように、私はすべての助けに感謝します
It depends on what you need to do to your XML. I have a similar setup where the table structure was made "generic" and anything product-specific was stashed into an XML field.
We also noticed the hard way that querying the XML is not exceptionally fast.... and using XML indices (which SQL Server offers, too) caused our database size to jump from roughly 1 GB to over 10 GB.....
What we're doing now for select elements from the XML is this:
With this, we can extract certain key values (e.g. "ProductID" or "ProductName") from the XML, and store them on the parent table as a column. It's computed, e.g. it's always up to date, and since it's also persisted, it's stored with the table data, e.g. it isn't constantly re-queried and re-computed. And since it's persisted with the table data, you can even put an index on it.
This works very well, but it only works for cases where you have isolated, single-value things that you want to fish out of the XML. For that case, it's a great solution, and it does speed up queries on those values by several orders of magnitude.
あなたの質問に正確に答えるわけではありませんが、あなたは別の検索戦略について考えたいと思うかもしれません。SQL Server / OracleとMySQLはすべて、大量のリレーショナルデータを格納するのに優れていますが、ほとんどの場合、テキストの検索に関してはそれほど優れていません（明らかに、これは検索対象とインデックスによって異なります）。
SQLよりもニーズに合っている可能性があるため、Luceneのような検索エンジンを少し時間をかけて検討することをお勧めします。
推定実行計画を表示します。
また：
SET STATISTICS IO ON
SET STATISTICS TIME ON