【问题标题】:SQL Server multiple index order optimizationSQL Server 多索引顺序优化
【发布时间】:2014-01-09 11:11:56
【问题描述】:

我有一个在 ID1 和 ID2 上按顺序包含非聚集索引 1 的表。

Select count(distinct(id1)) from table

返回 1

Select count(distinct(id2)) from table 拥有该表的所有值。

对该表的查询使用... where id1= XX and id2 = XX

如果我切换 index1 的字段顺序,是否可以提高性能?

我知道它应该更好,但也许:是因为 id1 只有 1 个值而无动于衷吗?

【问题讨论】:

  • 您的问题不清楚。您的查询有id,您的索引和where 子句有id1id2。你能试着更好地表达这个问题吗?样本数据和期望的结果很有帮助。
  • 抱歉,已编辑。现在是正确的。

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


【解决方案1】:

如果我理解正确,您是在比较这两种说法:

where id1= XX and id2 = XX

在大多数情况下,这将使用table(id1, id2)table(id2, id1) 上的索引。 where(或on)子句中的比较顺序对可以使用哪些索引没有影响。

是否应该在唯一索引中包含只有一个值的列是另一回事。拥有更复杂的索引会对性能产生较小的影响——树结构必须为每个键存储更多字节。但是,查询:

select count(distinct id2)
from table
where id1 = xx and idx = xx

实际上使用复合索引比使用单一索引table(id2) 运行更快。原因是复合索引可以用来完全满足查询(用行话来说,它是“查询的覆盖索引”)。单例索引需要在表数据中查找id1的值,需要额外处理。

【讨论】:

  • 所以这意味着在这种确切的情况下,无论索引列的顺序如何,在不使用复合索引或使用单例索引之间只会有很小的性能提升,因为所有的值id1 一样吗?
  • @user2920607 。 . .在大多数情况下,使用索引会比不使用索引执行得更好。单例需要在表数据中查找值。组合将覆盖查询,并且不需要任何额外的处理。复合材料的性能可能会稍好一些。
【解决方案2】:

您在索引中定义列的顺序很重要。如果您的列 ID1 将始终只有 1 个值,那么将其放入索引是没有意义的,除非您在非聚集索引中的覆盖索引中使用它(意味着索引不是表本身的物理排序)。通常,您在索引中定义的第一列应该是您需要搜索的具有最多可变值的列。以这种方式可视化它,如果您有一个包含 100 万行的表,并且索引中的第一列只有 1 个(或少量)不同的值,那么该索引会帮助您在 100 万行中找到您想要的行?还是先有ID2比较好,这样搜索效率更高,使用频率更高,这是你要问自己的问题。下面还有关于您的问题的更多信息。

SQL Server Clustered Index - Order of Index Question

如果您使用的是非聚集索引,如果您的索引中的第一列都是相同的值,那么它可能看起来不会产生差异。但是它确实很重要,原因是非聚集索引存储在多个页面上。您可以在页面上存储的条目越多,这有助于您更快地进行搜索。如果您在页面上包含没有为搜索增加任何价值的列,那么它将需要相同的索引来跨越更多页面。意味着更多的页面要翻阅和更长的查找。这也意味着在更新索引时插入期间向现有页面添加新条目的空间更少,从而导致更多页面拆分。因此,将只有 1 个值的列添加到索引的决定存在副作用。如果您使用列来“覆盖”常见选择中的检索值,那么您还可以在索引中使用包含列,它的额外好处是不重新排序您的索引,但就像一个涵盖索引一样。如果这是最初添加一个只有 1 个值的列的预期目的。

【讨论】:

  • " 一般来说,您在索引中定义的第一列应该是您需要搜索的具有最多变化值的列" 我知道这一点,但在这种情况下,如果 id1 的所有值是相同的,索引是非聚集的,我认为这可能没有区别查询是“更新字段1 ...其中id1 = XX和id2 = XX”
  • 它有所不同,它减少了非聚集索引的每个页面上的可用空间。这可能是一个小的差异,取决于你的情况。如果您在索引中使用的列不是用于搜索目的,而是作为“覆盖索引值”,那么您可以在索引中使用 Included Columns。
  • 在我的情况下,这不是一个涵盖的索引,因为更新的值不是索引定义中包含的值。总而言之,在我的情况下,索引工作正常,但它为每个页面使用了更多空间。我担心速度性能,并且更改索引顺序不会产生任何显着差异。感谢您的帮助,如果我错了,请纠正我
猜你喜欢
  • 1970-01-01
  • 2011-01-18
  • 1970-01-01
  • 1970-01-01
  • 2023-03-04
  • 1970-01-01
  • 2010-09-25
  • 2014-01-06
相关资源
最近更新 更多