Question

设置1 : 0..1关系的常用方法是：

PrimaryTable someID:(PK, identity)
ExtendedTable someID:(PK, FK)

如果随着时间的推移随机插入ExtendedTable的数据，它是否会在ExtendedTable的聚簇索引上产生碎片？这是SQL Server 2012应该担心的问题吗？

如果是这样，ExtendedTable有自己的PK，加上FK上的非聚集唯一索引会更好吗？

PrimaryTable someID:(PK, identity)
ExtendedTable id (PK, identity), someID (FK, NON-Clustered UNIQUE INDEX)

感谢。

Answer 1

简答：

我怀疑将整个子表作为单个B-Tree可能是最有效的配置（即同一字段上的PK和FK，具有聚簇索引）。

换句话说，您的第一个解决方案看起来不错。

长（呃）答案：

如果通过“碎片”表示索引页的逻辑顺序和物理顺序之间的差异，则不太可能通过在（单独的）FK字段上创建附加索引来解决它 - 您的查询仍需要通过FK索引。仍然是碎片化的（即使PK索引不是），只是因为你按照以前的顺序执行INSERT语句。

在您的情况下碎片是否真的会造成性能问题？您是否通过索引进行大范围扫描和使用小型缓存和使用机械驱动器（随机访问时间较差）？你真的测过了吗？

（如果通过“碎片”表示B树节点中未使用的空间，则可以进行与上述类似的参数。另请参阅Myth: Indexes Can Degenerate。）

即使您可以通过引入另一个索引以某种方式解决碎片问题，这是否值得维护额外索引，更多缓存压力以及可能double-lookup二级索引的价格？