所以让我先说我不能完全控制我的数据库设计，所以当前系统的很多方面都不能为了这个场景的目的而改变。
关于我们应该如何重新思考设计方面的评论可能是正确的，但无济于事:)
我有一个非常大的表，大约 150 个字段宽，大约 600m 行，它驱动大量进程。这是在数据仓库情况下，因此我们在计划加载过程之外没有任何更新/插入，因此它被大量索引。
已决定尝试对该表进行分区，我对索引分区表有一些担忧。我没有任何分区经验，因此感谢任何输入或链接。我无法在 BOL 或 msdn 上具体找到我所追求的内容。
目前，我们聚集在一个我们称之为IncidentKeyavarchar(50)而非唯一的字段上——我们可以有 1-100 条相同的记录IK（请不要发表评论）。我们确实经常在旧IncidentKey记录上获取新数据，因此它也不是连续的。
我知道我需要IncidentDate在我的聚集索引键中包含我的分区字段 ,才能使分区正常工作。我想它会是IncidentKey, IncidentDate。
问题是，如果“新”分区中的记录应该在聚集索引中“旧”分区中的记录之前，聚集索引的机制将如何在分区表中的 2 部分键上工作？
例如，我有 5 条记录：
IncidentKey Date
ABC123 1/1/2010
ABC123 7/1/2010
ABC123 1/1/2011
XYZ999 1/1/2010
XYZ999 7/1/2010
如果我得到一个新记录，ABC123, 2/1/2011它将需要在聚集索引BEFORE 中 XYZ999, 1/1/2010。这是如何运作的？
我假设有碎片和指针，但我找不到关于具有双部分键的分区表上非分区聚集索引的物理存储和配置的任何信息。
当谈论分区表和索引少于 100 个分区的表时，
没有未对齐的索引：
我的意思是：
非对齐索引
一个独立于其对应表分区的索引。
也就是说，索引具有不同的分区方案或放置在与基表不同的文件组中。
设计非对齐分区索引在以下情况下很有用：
基表尚未分区。
索引键是唯一的，不包含表的分区列。
您希望基表参与使用不同连接列的更多表的并置连接
是否还有其他性能缺陷：
1 - 减慢一些 DBCC 命令
2 - 在分区列以外的列上使用诸如 TOP 或 MAX/MIN 等运算符的查询可能会遇到分区性能降低的情况，因为必须评估所有分区。
3 -
使用分区消除的查询可能具有与大量分区相当或改进的性能。随着分区数量的增加，不使用分区消除的查询可能需要更长的时间来执行。