我在工作中遇到了一个非常特殊的性能问题!
在我们使用的系统中，有一个表保存有关当前工作流程的信息。其中一个字段包含一个电子表格，其中包含有关流程的元数据(不要问我为什么!!而且不，我无法更改它!!)
问题在于该电子表格存储在 SQL Server 2005 的 IMAGE 字段中(在与 SQL 2000 兼容的数据库集内)。
该表目前有超过 22K 行，甚至还有一个像这样的简单查询:
SELECT TOP 100 *
FROM OFFENDING_TABLE
在查询分析器中检索数据需要 30 秒。
我正在考虑更新对 SQL 2005 的兼容性(一旦我被告知该应用程序可以处理它)。
我想到的第二件事是将列的数据类型更改为 varbinary(max) 但我不知道这样做是否会影响应用程序。
我正在考虑的另一件事是使用sp_tableoption将行外大值类型设置为1，因为它当前0，但我不知道这样做是否会提高性能。
有谁知道在这种情况下如何提高性能？
<小时/>编辑以澄清
我的问题是，我无法控制应用程序向 SQL Server 提出的请求，我对其进行了一些反射(reflection)(该应用程序是一个 .NET 1.1 网站)，并且它使用了有问题的字段来处理我认为的一些内部内容。不知道它是什么。
我需要提高该表的整体性能。
最佳答案
我建议您检查有问题的表格布局健康状况:
select * from sys.dm_db_index_physical_stats(
db_id(), object_id('offending_table'), null, null, detailed);
还要查找的内容包括avg_fragmentation_in_percent、page_count、avg_page_space_used_in_percent、record_count 和ghost_record_count。高碎片、大量幽灵记录或低页面使用百分比等提示表明存在问题，只需从头开始重建索引(即表)即可大大改善情况:
ALTER INDEX ALL ON offending_table REBUILD;
我这样说是考虑到您无法更改表格或应用程序。如果您能够更改表格和应用程序，那么您已经得到的建议是很好的建议(不要使用“*”，不要选择无条件，使用较新的 varbinary(max) 类型等) .
我还会查看性能计数器中的平均页面生命周期，以了解系统是否内存不足。根据您对症状的描述，系统看起来受 IO 限制，这让我认为几乎没有页面缓存，更多的 RAM 以及更快的 IO 子系统可能会有所帮助。在 SQL 2008 系统上，我还建议打开页面压缩，但在 2005 上则不能。
而且，为了确保这一点，请确保查询不会被应用程序本身的争用所阻止，即。该查询不会花费这 30 秒中的 90% 来等待行锁。看sys.dm_exec_requests当查询运行时，查看 wait_time、wait_type 和 wait_resource。是 PAGEIOLATCH_XX 吗？或者它是一把锁？另外，sys.dm_os_wait_stats怎么样？在您的服务器中，最重要的等待原因是什么？
关于sql-server - 如何提高带有图像字段的 SQL Server 表的性能？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2253582/