与 NVARCHAR(MAX) 相比，SQL Server 中 XML 数据类型的性能损失是什么？
我有一个将保存日志条目的数据库。
日志表中的一列包含序列化（到 XML）对象，我团队中的一个人建议使用 XML 数据类型而不是 NVARCHAR(MAX)。 该表将“永远”保存日志（将来可能会考虑归档一些非常旧的条目）。
我有点担心 CPU 开销，但我更担心 DB 会增长得更快（引用问题中的 FoxyBOA 在使用 XML 时获得了 70% 更大的 DB）。
我已阅读此问题并且它给了我一些想法，但我特别感兴趣的是澄清数据库大小是增加还是减少。
您能否分享您在这方面的见解/经验？
顺便提一句。目前，我不需要依赖 SQL Server 中的 XML 功能（在特定情况下，对我来说优势几乎为零）。有时会提取日志条目，但我更喜欢使用 .NET 处理 XML（通过编写小型客户端或使用 .NET 程序集中定义的函数）。
I have a database that is going to keep log entries.
One of the columns in the log table contains serialized (to XML) objects and a guy on my team proposed to go with XML data type rather than NVARCHAR(MAX).
This table will have logs kept "forever" (archiving some very old entries may be considered in the future).
I'm a little worried about the CPU overhead, but I'm even more worried that DB can grow faster (FoxyBOA from the referenced question got 70% bigger DB when using XML).
I have read this question and it gave me some ideas but I am particularly interested in clarification on whether the database size increases or decreases.
Can you please share your insight/experiences in that matter.
BTW. I don't currently have any need to depend on XML features within SQL Server (there's nearly zero advantage to me in the specific case). Ocasionally log entries will be extracted, but I prefer to handle the XML using .NET (either by writing a small client or using a function defined in a .NET assembly).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您确实有 XML，并且可以确定它始终是 XML，那么我肯定会建议您采用这种方式。 SQL Server 以优化的格式存储 XML - 您甚至不需要任何 XML 索引即可从中受益。
如果将 5KB XML 的 5000 行插入到 XML 列中，则大约会获得 1250 页 = 9 MB。将具有相同 5KB XML 的相同 5000 行插入 NVARCHAR(MAX) 使用超过 3700 个页面或 29 MB - 差别很大！
如果您可以将 XML 与存储在 SQL Server 中的 XML 模式关联起来，那么这种差异应该会更加明显。另外，您还可以保证存储的 XML 符合架构 - 有时会非常有帮助！无法使用普通的 NVARCHAR(MAX) 列来做到这一点...
并且我不同意使用 XML 而不是 NVARCHAR(MAX) 会带来任何性能损失 - 恰恰相反。由于当您要显示或获取内容时，您可能会从 SQL Server 检索较少的数据，因此我认为它甚至比 NVARCHAR(MAX) 快一点。
If you do have XML, and you can be sure it's always XML, I would definitely recommend going that way. SQL Server stores XML in an optimized format - you don't even need any XML indices on that to benefit from it.
If you insert 5000 rows of a 5KB XML into an XML column, you get roughly 1250 pages = 9 MB. Inserting the same 5000 rows with the same 5KB XML into NVARCHAR(MAX) uses over 3700 pages or 29 MB - quite a difference!
And that difference should be even more pronounced if you can associate your XML with a XML schema stored in SQL Server. Plus you're also guaranteed that the XML stored conforms to a schema - can be very helpful at times! Can't do that with a plain NVARCHAR(MAX) column...
And I don't agree that using XML over NVARCHAR(MAX) has any performance penalty - quite the contrary. Since you're potentially retrieving less data from SQL Server when you're about to display or fetch the content, I would argue it's even a tad faster than NVARCHAR(MAX).
该基准测试显示 XML 数据类型使用的 IO 比 VARCHAR(MAX) 少，但 CPU 多一点。我认为 NVARCHAR(MAX) 会花费更多的 IO，因为它是 unicode。
http://searchsqlserver. techtarget.com/tip/XML-data-type-in-SQL-Server-2005-vs-VARCHAR-MAX
This benchmark shows XML data type using less IO but a little more CPU than VARCHAR(MAX). I would think NVARCHAR(MAX) would take even more IO since it's unicode.
http://searchsqlserver.techtarget.com/tip/XML-data-type-in-SQL-Server-2005-vs-VARCHAR-MAX