相关疑难解决方法(0)

如果聚簇索引不是唯一的,会发生什么？是否会导致性能不佳,因为插入的行会流向某些类型的"溢出"页面？

它是"独特的",如果是这样的话怎么样？使它独一无二的最佳方法是什么？

我问,因为我目前正在使用聚集索引来划分逻辑部分中的表,但性能是如此,最近我得到了使我的聚簇索引唯一的建议.我想就此发表第二个意见.

谢谢!

我的两个问题是:

• 我可以使用聚簇索引来加速大表中的批量插入吗？
• 如果我的IDENTITY列不再是聚集索引,我还能有效地使用外键关系吗？

详细说来,我有一个包含公司数据的几个非常大(在100-1000万行之间)的数据库.通常,在这样的表中存在大约20-40个公司的数据,每个公司都是由"CompanyIdentifier"(INT)标记的他们自己的"块".此外,每家公司都有大约20个部门,每个部门都有自己的"子块",标有"DepartmentIdentifier"(INT).

经常会发生从表中添加或删除整个"块"或"子块".我的第一个想法是在这些块上使用表分区,但由于我使用的是SQL Server 2008标准版,因此我无权使用它.尽管如此,我所拥有的大多数查询都是在"块"或"子块"上执行而不是在整个表格上执行.

我一直在努力为以下功能优化这些表:

1. 在子块上运行的查询
2. 作为整体在桌面上运行的"基准测试"查询
3. 插入/删除大块数据.

对于1)和2)我没有遇到很多问题.我在关键字段上创建了几个索引(也包含有用的CompanyIdentifier和DepartmentIdentifier),查询运行正常.

但对于3)我一直在努力寻找一个好的解决方案.我的第一个策略是始终禁用索引,批量插入大块并重建索引.这在开始时非常快,但现在数据库中有很多公司,每次重建索引需要很长时间.

目前我的策略已经改为只是在插入时保持索引,因为现在这似乎更快.但我想进一步优化插入速度.

我似乎注意到通过添加在CompanyIdentifier + DepartmentIdentifier上定义的聚簇索引,将新的"块"加载到表中的速度更快.在我放弃这个策略以支持在IDENTITY列上添加聚簇索引之前,有几篇文章向我指出聚簇索引包含在所有其他索引中,因此聚簇索引应该尽可能小.但现在我正在考虑恢复这个旧策略来加速插入.我的问题,这是明智的,还是会在其他领域遇到性能打击？这真的会加速我的插入还是仅仅是我的想象力？

我也不确定在我的情况下是否确实需要IDENTITY列.我希望能够与其他表建立外键关系,但我是否也可以使用类似于CompanyIdentifier + DepartmentIdentifier + [uniquifier]方案的东西？或者它必须是一个表格,分散的IDENTITY数字？

非常感谢任何建议或解释.