Pet*_*ter 6 sql sql-server indexing identity-column clustered-index
我们有一个遗留数据库,它是一个sql server db(2005和2008).
表中的所有主键都是UniqueIdentifiers.
这些表当前没有在它们上创建聚集索引,我们在仅有750k记录的表上遇到性能问题.这是我使用唯一标识符作为唯一主键的第一个数据库,我从未见过sql server返回数据这么慢.
我不想在uniqueidentifier上创建聚簇索引,因为它们不是顺序的,因此在插入数据时会降低应用程序的速度.
我们无法删除uniqueidentifier,因为它用于远程站点记录身份管理目的.
我曾考虑过向表中添加一个大整数标识列,并在此列上创建聚簇索引并包含唯一标识符列.
即
int identity - 保持插入速度唯一标识符的第一列 - 确保应用程序按预期保持工作.
目标是改进身份查询并加入表查询性能.
问题1:这会改善数据库的查询性能还是会降低它的速度？
Q2:有没有我没有列出的替代方案？
谢谢皮特
编辑: 性能问题是通过select语句快速检索数据,特别是如果一些更"交易/更改"的表连接在一起.
编辑2:表之间的连接通常都在主键和外键之间,对于具有外键的表,它们包含在非聚集索引中以提供更多覆盖索引.
这些表都没有其他值可以提供良好的聚簇索引.
我更倾向于在每个高负载表上添加一个额外的标识列,然后在聚簇索引中包含当前的Guid PK列以提供最佳的查询性能.
编辑3:我估计只有80%的查询是通过数据访问机制单独在主键和外键上执行的.通常,我们的数据模型具有延迟加载的对象,这些对象在访问时执行查询,这些查询使用对象id和PK列.我们有大量用户驱动的数据排除/包含查询,它们使用外键列作为基于类型X的条件的过滤器,不包括以下id.剩下的20%是Enum(int)或日期范围列的子句,在系统中执行的文本查询非常少.
在可能的情况下,我已经添加了覆盖索引来覆盖最重的查询,但到目前为止,我仍然感到失望.蓝脚表示数据存储为堆.
如果表上没有聚集索引，它将存储为堆而不是 B 树。堆数据访问在 SQL Server 中绝对是非常糟糕的，所以你肯定需要添加聚集索引。
我同意您的分析，即 GUID 列对于聚类来说是一个糟糕的选择，特别是因为您无法使用 NEWSEQUENTIALID()。如果您愿意，您可以创建一个新的人工整数键，但如果有另一列或列组合可以作为聚集索引，那也可以。
您是否有一个经常用于范围扫描的字段？哪些列用于连接？除了 GUID 之外，是否存在也唯一标识行的列组合？发布数据模型的样本将帮助我们建议一个好的聚类候选者。