我正在使用 Lucene 对 CMS 的内容进行索引,因此我扩展了 SQL Server 数据库模式以添加“IsIndexed”位列,因此 Lucene 索引器可以找到一段尚未出现的内容索引。
我在表中添加了一个索引,Content
因此对列的查找IsIndexed
应该更快。这是数据库的样子:
CREATE TABLE Content (
DocumentId bigint,
CategoryId bigint,
Title nvarchar(255),
AuthorUserId bigint,
Body nvarchar(MAX),
IsIndexed bit
)
CREATE TABLE Users (
UserId bigint,
UserName nvarchar(20)
)
存在以下索引:
Content (
PK_Content (Clustered) : DocumentId ASC
IX_CategoryId (Non-Unique, Non-Clustered) : CategoryId ASC
IX_AuthorUserId (Non-Unique, Non-Clustered) : AuthorUserId ASC
IX_Indexed_ASC (Non-Unique, Non-Clustered) : IsIndexed ASC, DocumentId ASC
IX_Indexed_DESC (Non-Unique, Non-Clustered) : IsIndexed DESC, DocumentId ASC
)
Users (
PK_Users (Clustered) : UserId
)
这是用于查找非索引内容的查询:
SELECT
TOP 1
Content.DocumentId,
Content.CategoryId,
Content.Title,
Content.AuthorUserId,
Content.Body
Users.UserName
FROM
Content
INNER JOIN Users ON Content.AuthorUserId = Users.UserId
WHERE
IsIndexed = 0
但是,当我运行它时,实际执行计划会报告 PK_Content 的聚集索引扫描以及 PK_Users 的聚集索引搜索。查询执行大约需要 300 毫秒。
当我修改查询以删除 Users.UserName 字段和用户内部联接时,查询需要大约 60 毫秒才能运行,并且没有针对 PK_Content 的聚集索引扫描,只有针对 PK_Content 的聚集索引搜索。
我在为列添加降序索引之前和之后都尝试了这个Content.IsIndexed
,我还添加Content.DocumentId
了 IX_Indexed 索引,但没有任何区别。
我究竟做错了什么?我已经制作了所有必要的索引(然后是一些)。Content 表有数十万行,Users 表也是如此,所以我不明白为什么优化器会选择扫描。