我在一个有几百万行的表上遇到性能问题，这些行在很短的时间内（每分钟数百个）被查询很多。
为简化起见，表格如下：
Id UserId ValueA ValueB ValueC Etc
--------------------------------------------
1 1 X X X "
2 1 X X X "
3 2 X X X "
4 2 X X X "
5 2 X X X "
6 3 X X X "
我经常查询UserId列上的表格，然后查看所有相关的行和列。
现在，我正在获得自动Azure建议，以便在UserId上创建索引，并将其他列作为包含的列。据我所知，它只是复制了整个数据。
现在我想我是否可以通过使UserId聚集索引来解决这个问题。
除了大量的读取之外，这个表有时会遭受很多插入（在某些时刻可能每分钟有数百个单独的行，但现在不能进行批处理）
我只是担心这些单独的Insert会越来越慢，因为它需要不断地物理移动数据以保持聚簇索引的完整。
我知道最后我需要全部测试，但这里有指导吗？
是否存在类似指南的内容，即对于包含大量单个插入的表，总是将聚簇索引放在标识列上？
答案 0 :(得分：1)
嗯，有一个指南，对于一个有很多单独插入的表，识别列上的聚簇索引是个好主意。这是因为插入转到表的“结尾”，并且不会导致页面拆分。
Here是关于该主题的有趣讨论。
具有讽刺意味的是，创建索引并包含所有列只会将问题转移到索引。我不确定这是不是一个好主意。
答案 1 :(得分：0)
我之前遇到过这个问题。我发现有多个索引运行良好。目标是不要将每个属性编入索引，但如果您注意到要查询单个属性或一些属性，则通常会将这些属性与您的密钥一起编入索引。需要注意的是，这会占用大量数据，因为每个索引都是表的副本，因此随着表的增长，插入也会增加。这也可能会影响插入时间，但如果您查询的次数多于插入次数，则可能会有用。
我知道在Microsoft SQL Server Management Studio（SSMS）中，有一种方法可以查看查询执行程序获取响应输出所用的确切路径，这也说明了它花费最多时间的位置。这将是开始查看字段索引位置的好地方。