我有一个100米+行的桌子。 随着数据的增长，我们看到查询性能非常差。 我注意到行大小非常大（10190），我认为这影响了索引/索引性能。
该表有一堆列设置为错误的数据types（大量ints tinyint更合适，等）。 我去了，更新了桌子，改变了我所能做的。
原始的行大小是10190，我可以通过调整smallint或tinyint的int来将其降至10090。
有两列设置为varchar（2048）。 我将它们更改为varchar（max），行大小降低到大约6000。
我使用在这里find的查询http://www.sqlservercentral.com/Forums/Topic226699-5-1.aspx获取行大小。
我的问题是：更改varchar（2048）列varchar（max）帮助索引/性能时，这些列不经常使用？ 如何获得8000以下的行大小？
VARCHAR(2048)和VARCHAR(MAX)之间基本上没有区别。 一个溢出到“行溢出”分配单元中，另一个溢出到BLOB分配单元中， 见表和索引组织 。 large value types out of row表选项中的large value types out of row的默认设置为0，因此，除非已更改，否则VARCHAR(MAX)将尽可能保留在行中，就像VARCHAR(2048)一样。
我build议运行sys.dm_db_index_physical_stats并获取实际的最大，最小和平均行大小，以及avg_page_space_used_in_percent 。 这将给出真实的行大小的更准确的图像，而不是理论上的声明大小。
首先我要检查的是聚集索引。 如果使用复合索引，它应该被设置为狭窄的，一列或者尽可能less的列。 理想情况下，它应该设置为可以顺序的东西，比如bigint，而不是uniqueIdentifier。 如果使用uniqueIdentifier聚簇索引，有些人通过添加bigint聚簇索引并将uniqueIdentifier作为唯一索引来看到性能改进。
SSMS有时会有索引可能丢失的有用信息：
http://msdn.microsoft.com/en-us/library/ms345524%28v=SQL.100%29.aspx
接下来的事情就是分析查询。 找出哪些查询消耗最多的时间，并确定它们是否正在覆盖索引或执行表扫描。 您可能需要发布一些sql查询和现有索引的详细信息。
查询是否只写请求所需的数据，即没有SELECT *？
我会检查SQL服务器的整体设置，validationconfiguration是否遵循推荐的做法（请参阅Brent Ozar的优秀清单 ）; 那么也许运行一些perfmon来查看你的瓶颈在哪里，首先检查磁盘队列的长度。