非聚集索引不起作用答案

【问题标题】：Non Clustered index not working非聚集索引不起作用
【发布时间】：2014-11-03 12:13:03
【问题描述】：

我有一个包含超过 70000 条记录的表，如果我选择前 60 行，它会扫描整个聚集索引，执行大约需要 7 到 8 秒。我已经定义了非聚集索引，但那些不起作用下面是详细信息。

聚集索引：ID 非聚集索引：UserTypeId、LocationId 和 CityId

            SELECT TOP ( 60 )
                    UP.Id AS UserId ,
                    UP.FirstName ,
                    UP.LastName ,
                    UP.City ,
                    UP.ImageURL ,
                    0 AS ActivityCount ,
                    UP.IsPublic ,
                    ISNULL(UP.GemsCount, 0) AS GemsCount ,
                    ISNULL(UP.PointCount, 0) AS PointsCount ,
                    ISNULL(UP.FriendsCount, 0) AS FriendsCount ,
                    FORMAT(UP.LastUpdatedDate, 'MM/d/yyyy HH:m:ss tt','en-US') LastUpdatedDateText,
                    Neighbourhood,
                    UP.UserTypeId,
                    UP.CityId,
                    UP.LocationId

            FROM    UserProfiles AS UP 
            WHERE   
                     UP.UserTypeId = 1
                     AND UP.LocationId > 0
                     AND UP.CityId > 0
            ORDER BY UP.LastUpdatedDate DESC

【问题讨论】：

查询优化器已经确定——基于表的统计信息——全表扫描比使用其他索引更有效。但是，对于 70,000 行的此查询，7-8 秒似乎很长。

标签： sql-server

【解决方案1】：

原因是查询的最后一部分：

ORDER BY UP.LastUpdatedDate DESC

要么取消它，要么将列添加到 NC 索引中，你应该没问题。与往常一样，这种建议可能会在其他地方造成更多麻烦，因此请对其进行测试，等等。

【讨论】：

我在 LastUpdatedDate 创建了 NC。谢谢
无用的建议 - 就像我的例子。问题不是 order by，而是 where 子句。假设 location 和 city id 是普通的 id 字段，FILTER 不会过滤任何内容。用户类型 id 的基数可能较低 - 因此 NC 索引被忽略（因为它没有足够的过滤）当 locationId 和 CityId 是“真实”值时 - 仍应使用 NC 索引 - 然后将结果排序为临时数据库。在这种情况下，现在有帮助的 LastUpdatedDate 索引可能完全不相关。
@TomTom 无论如何，它根据 OP 工作，所以它必须有一些东西;)