SQL Server 2008-手動解析XML，還是對XML字段使用內置的XML索引？

Question

我正在使用SQL Server 2008中的日志記錄數據庫。它主要由一個這樣的表組成：

StepLog 
----------------
  StepLogID
  ClientID
  LogContent   XML
  CreateDate

基本上，此表中將發生的事情是各個客戶端會將某些活動記錄到該表中。 LogContent字段將為XML-無類型，因為我們不知道客戶端要記錄什么內容。

為了允許搜索LogContent字段，當前計划是以編程方式切碎LogContent字段。 用於粉碎的元數據將在表中，如下所示：

XPathAttribute
----------------
  XPathAttributeID
  AttributeName
  AttributeDescription
  XPath

將記錄插入到StepLog中之后，我們將擁有一個存儲過程，該存儲過程將采用XPathAttribute中定義的所有Xpath，並將它們寫到另一個表XPathAttributeValue中。

XPathAttributeValue
----------------
  XPathAttributeValueID
  StepLogID
  AttributeID
  AttributeValue 

在查看此設計時，我的最初想法是“為什么不只使用XML索引，包括主索引和次索引？這將避免我們這邊的大量工作，而是使用內置功能。

我對XML索引沒有太多的經驗，並且原始設計者在SQL Server2005中對XML索引（性能差）有一些不好的經驗，這就是這種設計的起源。

反饋將不勝感激！

謝謝西爾維亞

Answer 1

XML索引在特定情況下有幫助，如“ 輔助XML索引”中所述 ：

以下是創建一個或多個二級索引的一些准則：

• 如果您的工作負載在XML列上大量使用路徑表達式，則PATH輔助XML索引可能會加快您的工作負載。 最常見的情況是在Transact-SQL的WHERE子句中的XML列上使用exist()方法。
• 如果您的工作負載通過使用路徑表達式從單個XML實例中檢索多個值，則在PROPERTY索引中將每個XML實例內的路徑聚集起來可能會有所幫助。 當獲取對象的屬性並且其主鍵值已知時，此情況通常發生在屬性包情況中。
• 如果您的工作負載涉及在XML實例中查詢值而又不知道包含這些值的元素或屬性名稱，則可能需要創建VALUE索引。 這通常發生在后代軸查找中，例如//author[last-name="Howard"] ，其中元素可以出現在層次結構的任何級別。 它也發生在通配符查詢中，例如/book [@* = "novel"] ，在該查詢中查找具有某些屬性的值為“ novel”的<book>元素。

如您所見，每種類型的索引都適用於特定情況。 使用像您的項目這樣的開放式方法，很難說出哪些索引會有所幫助，而哪些則無濟於事。

要考慮的另一件事是，如果可以為列聲明XML模式，則XML的性能要好得多，但是項目的性質不允許這樣做。

因此，總的來說，我會說...進行觀察。 將XML切碎並將值存儲在關系表中，很可能會提高原始XML訪問的性能。 但這適用於您了解架構並切出一組特定信息，然后正確索引的情況。 現在，即使您切碎了一些信息，您也將其切碎成基本上是EAV結構，這既難以查詢又無法優化。 我還建議您閱讀有關性能和可伸縮性的語義數據建模最佳實踐，以獲取有關EAV缺點以及如何避免某些問題的一些討論。

Answer 2

我基本上同意@Remus所說的。

也就是說，一定要使用內置的XML索引。 SQL Server可以很好地處理龐大的XML集合（IMHO）。 通過滾動自己節省的時間將是無法估量的。

我要提到的一件事-添加架構會損害我的性能 。 我希望它能對查詢優化器有所幫助，但沒有幫助，所以我就省略了。 （您說過它是未鍵入的，所以不應該出現。）