如果存在具有聚集主键(UserID long,OrderID long)的表UserOrder。
constraint PrimaryKey_UserOrder primary key clustered ( UserID, OrderID)我发现在这个表中插入越来越多的记录(>100万条)后,下面的count查询会变得越来越慢。
select COUNT(UserID) from UserOrder where UserID = <some value> 但是,如果我仅为UserID引入另一个非聚集索引。
create nonclustered index Index_UserOrder_UserID on UserOrder (UserID)因为使用了新的索引而不是主键,所以查询会变得更快。
我不确定这个新索引是否真的对COUNT()的性能有所帮助。也不知道为什么。
有什么意见吗?
注意:一个用户id可能有数百万个订单。
发布于 2016-02-01 12:09:35
根据表的其余部分的结构,该索引应该有助于提高查询的性能。让我们把它分解一下。您的群集主键为on (UserID,OrderID)。因为它是聚集索引,这意味着表中每隔一列就是一个包含列(即存在于叶级别)。这就是说,在叶级别,索引将是宽的。与UserID上的非聚集索引形成对比。因为您在叶级别没有表的其他列(除了OrderID),所以这个索引将更加紧凑,因此需要更少的读取来满足查询。可以通过使用set statistics io on并强制您的查询使用这两个索引中的任何一个来证明这一点。使用非聚集索引执行的读操作应该少得多。
https://stackoverflow.com/questions/35122514
复制相似问题