我不是DBA（“好！”，你马上就会想。）
我有一个记录数据表，其中包含以下特征和使用模式：
datetime列，其值不断增加且主要（但仅限于大多数）唯一此外，目前还有一个日常维护窗口，在此期间我可以进行表格优化。
我坦率地说，即使我对它进行了错误的索引，我也不希望这个表能够挑战它将要启动的服务器，但是它似乎是一个在SQL Server聚簇索引上请求输入的好机会。 / p>
我知道聚簇索引确定实际表数据的存储（数据存储在索引本身的叶节点中），而非聚簇索引是指向数据的单独指针。因此，在查询术语中，聚簇索引将比非聚集索引更快 - 一旦我们找到了索引值，数据就在那里。插入和删除都有成本（当然，更新聚簇索引列的值的更新将特别昂贵）。
但我读了in this answer，除非重建索引，否则会删除不会被清理的留下的空白。
所有这些都告诉我，我应该：
我是否非常偏离那里？我是否需要经常重建索引以避免浪费大量空间？还有其他显而易见的（对于DBA）我应该做的事情吗？
提前致谢。
答案 0 :(得分：5)
与许多人认为的相反，在表上拥有良好的聚簇索引实际上可以使INSERT之类的操作更快 - 是的，更快！
查看由金伯利·特里普（Kimberly Tripp）撰写的开创性博文The Clustered Index Debate Continues.... - 最终的索引女王。
她提到（大约在文章的中间）：
群集中的插入速度更快 桌子（但只在“右边” 聚集表）比一个 堆。这里的主要问题是 在IAM / PFS中查找以确定 堆中的插入位置是 比集群表中的速度慢 （插入位置已知， 由聚簇键定义）。插入 插入表格时速度更快 定义顺序（CL）和位置 这个顺序不断增加。
关键点在于：只有正确的聚簇索引才能获得好处 - 当聚簇索引是唯一的，狭窄的，稳定的并且最佳地不断增加时。这最适合使用INT IDENTITY列。
Kimberly Tripp还有一篇很棒的文章，介绍了如何为您的表格选择最佳的聚类键，以及它应该达到的标准 - 请参阅她的帖子，标题为Ever-increasing clustering key - the Clustered Index Debate..........again!
如果您有这样的专栏 - 例如代理主键 - 使用它作为您的群集键，您应该会在桌面上看到非常好的表现 - 即使在很多INSERT上也是如此。
答案 1 :(得分：3)
有两种“最佳实践”方法可以为高流量日志记录表编制索引：
DEFAULT NEWSEQUENTIALID() 这两种方法都允许SQL Server有效地扩展表，因为它知道索引树将在特定方向上增长。
除非存在特定的性能问题，否则我不会在表上放置任何其他索引，也不会安排索引的重建。
答案 2 :(得分：3)
我同意将聚集索引放在timestamp列上。我的查询将在fillfactor上 - 100％以牺牲写入性能为代价提供最佳读取性能。页面拆分可能会对您造成伤害。选择较低的fillfactor会以牺牲读取性能为代价来延迟页面拆分，因此它是一种很好的平衡方式，可以最好地适应您的情况。
批量删除后，重建索引并更新统计信息。这不仅可以提高性能，还可以将索引重置为指定的fillfactor。
最后，是的将非聚簇索引放在其他适当的列上，但只选择那些非常选择的列，例如不是位字段。但是请记住索引越多，这会影响写入性能
答案 3 :(得分：0)
显而易见的答案取决于您将如何查询它。索引的要点是在选择数据时减少比较的数量。当您考虑将要加载的数据和存储的阻塞因子时，聚簇索引会有所帮助（您可以在一次读取时将64k块中的一堆数据加载）。如果您包含ID和日期时间作为主键，但不在选择条件中使用它们，则它们将不会做任何事情，只会妨碍您的表现。这就是人们在加载数据之前通常在批量插入时删除索引的原因。