我管理一个SQL Server 2008 R2单实例服务器。我有一张是我最大的桌子，也是我最常用的桌子。它基本上是一个事件表，每天记录大约400k事件，并保存13个月的历史。
为了解决此问题，更改此表的设计或其中的数据不是一种选择。因为这个表是
管理此表上的索引是一个熊。
该表当前有1个聚簇索引（int标识字段上的PK）和23个非聚簇索引。总索引存储空间为372 GB，比表本身大9倍。该表每天更新一次，然后所有其他活动都是“SELECT”语句。 WHERE子句中使用的大多数字段都是varchar（50）字段，还有一些日期时间字段。
在性能方面，该表几乎在所有情况下都能快速查询，因此没有任何投诉......
ASK：
我只是想知道是否有更好的方法来索引此表，使其更“通用”，以支持可以查询的多种方式，而不占用太多的磁盘空间...思考？在这样的情况下寻找一些高级理论或一般最佳实践。
答案 0 :(得分：1)
最佳索引IMO是基于使用情况的 - 运行Profiler，并捕获为此表运行的查询并对这些查询进行微调。
如果您能够更改分区或群集索引策略，这将为您带来巨大的推动。
问：为什么在用于报告目的的表上的标识列上有PK？是否在public中大量使用？如果不是，那仅仅是为了独特吗？
答案 1 :(得分：1)
您可以检查是否有可以合并为一个索引的索引。 - INCLUDED列的列顺序无关紧要。例如：
Index 1:
Key Columns (A, B, C, D, E) Includes (L, M, N)
Index 2:
Key Columns (A, B, C, D, E, F, G) Includes (N, M, L)
因此您可以删除索引1.但是您可以执行更多I / O，因为索引2更大。 另一方面，您不必在RAM和磁盘/备份中拥有两个索引。
也可能是改变选择性较低的索引列的顺序不会花费太多。您可能知道索引中键列的顺序应该是从最具选择性的列到更多和更少的选择列。
您是否希望实际数据的索引策略与旧数据相同？因此，您可以使用筛选索引，为较旧的数据使用较少的索引，为较新的数据使用更灵活的索引策略。可能无法像现在这样快速查询旧数据。但与新数据相比，查询的频率是多少？