【问题标题】:SQL query with multiple indexes - SQL server 2000具有多个索引的 SQL 查询 - SQL Server 2000
【发布时间】:2010-01-29 12:36:36
【问题描述】:

我使用类似这样的查询

select.....from.. with... (INDEX=IX_TABLE_1, INDEX=IX_TABLE_2)...

我收到以下错误

每个表只有一个索引提示列表 允许

这似乎在 SQL Server 2005 上运行良好。这是 SQL Server 的问题吗?

【问题讨论】:

  • 我已经为您提供了更详细的解释。索引提示真的应该很少使用。 (尽管尝试不同的选项并暂时强制使用特定索引可能是一个很好的学习工具。)

标签: sql sql-server-2005 sql-server-2000 indexing


【解决方案1】:

认为这可能是因为您使用的语法。

代替 (INDEX=IX_TABLE_1, INDEX=IX_TABLE_2),尝试:

(INDEX=IX_TABLE_1, IX_TABLE_2)

我认为这是因为你有 2 个 "INDEX=" 部分。

另外,我建议仅将索引提示作为最后的手段,因为查询优化器通常应选择最佳计划/索引来使用。这就是为什么通常应该信任优化器的原因。如果您确实使用了索引提示,最好经常查看它们,因为它们可能会随着时间的推移而变得更糟(例如,随着数据量的增长,最初在提示中表现更好的部分可能会开始表现更差)。

【讨论】:

  • 谢谢!实际上这对我有用 INDEX(IX_TABLE_1, IX_TABLE_2)
【解决方案2】:

实际上,您一开始就不应该给出索引提示。

说明

  1. SQL 语言背后的目标之一是将“什么”与“如何”分开。换句话说;您的查询应该指出您需要的结果集的规则,而不是数据访问路径(这正是索引提示所做的)。
  2. 通过将查询绑定到特定索引,您将无法通过添加更好的索引来提高性能。 IE。您还必须修改查询。
  3. 许多提示选项是特定于平台的;使用它们时会降低便携性。
  4. 已编写查询优化器以考虑所有索引、各种连接方案,最重要的是;表中数据的统计信息。即使您能够自己涵盖所有这些基础,并确定今天要使用的理想索引;在 6 个月的时间里,您的数据库中某些值、记录、引用的统计频率可能已经改变 - 您的索引选择可能不再有任何好处!

旁注

如果优化器似乎对使用哪些索引做出了愚蠢的选择;这通常需要进一步调查。

  • 作为第一步;您的表格统计信息是否是最新的?
  • 其次,确保优化器不会拒绝特定索引,因为实际上所述索引会降低性能。例如,您可能很想执行以下操作之一:

    SELECT  Col1, Col2, Col3, ...
    FROM    Customers WITH (INDEX=IndexByName)
    WHERE   FistName LIKE 'A%'
    
    SELECT  Col1, Col2, Col3, ...
    FROM    Customers WITH (INDEX=IndexByName)
    ORDER BY FirstName
    

索引提示看起来完全合乎逻辑;但是:

  • 如果索引是聚集索引或覆盖索引:无论如何都会使用它 - 没有提示。
  • 如果索引是非聚集索引和非覆盖索引:检索到的每条记录都需要进行书签查找。这会产生巨大的开销;特别是在磁盘寻道活动上。因此,索引毕竟是一个糟糕的选择。

终于

我不确定是不是这样;但您的问题并不表明它是一个复杂的多表查询。那么它实际上可能像下面这样微不足道吗?

SELECT  Col1, Col2, ...
FROM    ATable WITH (INDEX=Index1, INDEX=Index2)

无论在什么情况下,提示单个表的多个索引肯定没有任何意义(除非它通过自连接多次使用)。你说:

这似乎适用于 SQL Server 2005。

我不得不问:你确定吗?
我试过了;并且尽管它没有导致错误消息 - 它严重混淆了优化器。它迫使优化器遍历同一个表两次(不必要地)并将结果集相互连接 - 产生巨大的开销!!

【讨论】:

  • 为什么不呢?我在这里错过了什么??
猜你喜欢
  • 2011-11-20
  • 2012-07-31
  • 2017-10-20
  • 2016-03-25
  • 2011-10-13
  • 2014-03-07
  • 2018-06-26
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多