【问题标题】:How to improve perofrmance of Non selective Index?如何提高非选择性索引的性能?
【发布时间】:2013-09-15 08:21:12
【问题描述】:

根据建议索引必须是最有选择性的以提高性能。作为一般准则,我们应该在经常被查询少于表的 15% 行的表上创建索引。索引列/列中不同值的数量与表中记录数的比率表示一个索引。

具有良好选择性的示例 一张有 100'000 条记录的表,其中一个索引列有 88000 个不同的值,则该索引的选择性为 88'000 / 10'0000 = 0.88。

现在说到重点。我有一张有 1,80,000 条记录的表。 搜索条件中经常使用的字段是 (1) 使用用户名搜索记录。 字段类型:-> 非空,nvarchar(32)。 唯一记录为 627 (2) 使用Active_date 搜索记录。 字段类型:-> DateTime,Null。 唯一记录是 85627 。 (3) 使用 Current_state 搜索记录 字段类型:-> 非 Null,nvarchar(32)。 唯一记录只有 2 条,分别是“Pending”和“Closed”。

目前所有上述字段都已编入索引。就选择性而言,情况 (1) 和 (3) 不是最有选择性的,我应该如何处理它们以提高性能?

提前致谢,山姆

【问题讨论】:

    标签: sql sql-server indexing query-performance


    【解决方案1】:

    选择性并不能说明全部。假设有 10 个待处理的申请和 1.000.000 个已关闭的申请。那么关于状态的索引不是很有选择性,但还是很有用的!该索引将帮助人们快速浏览待处理的申请,这可能是他们经常做的事情。

    另一个例子是票务系统。大部分工作都是在公开票上完成的。因此,虽然票证的状态不是很挑剔,但它仍然是索引的绝佳候选者。

    附:只有索引中最左边的已知列可用于解析搜索。例如:

    select * from Users where name = 'fred'
    

    (name) 上的索引可用于解析此查询,但(active_date, name) 上的索引不能。

    【讨论】:

    • 谢谢,是的,我同意 Sql Server 正在使用 Here 索引,并且我也获得了性能。但我只是想知道选择性索引概念。我们如何处理非选择性索引?
    猜你喜欢
    • 1970-01-01
    • 2011-09-17
    • 2012-04-30
    • 2020-03-05
    • 2016-05-23
    • 2015-04-28
    • 1970-01-01
    • 2023-01-20
    • 1970-01-01
    相关资源
    最近更新 更多