【问题标题】:Adding a non clustered index to a table with less than 1000 rows but accessed frequently will increase performance?向少于 1000 行但经常访问的表添加非聚集索引会提高性能吗?
【发布时间】:2011-12-17 02:11:36
【问题描述】:

我有一个只有 400-500 行的表,但该表经常被访问,所以我想知道是否应该在其中一个列上添加非聚集索引以查看任何改进?

此表始终保持相同的数据,很少更新。

这是表格的结构

CREATE TABLE [dbo].[tbl_TimeZones](
    [country] [char](2) NOT NULL,
    [region] [char](2) NULL,
    [timezone] [varchar](50) NOT NULL
) ON [PRIMARY]

使用此集群索引:

CREATE CLUSTERED INDEX [IX_tbl_TimeZones] ON [dbo].[tbl_TimeZones] 
(
    [country] ASC,
    [region] ASC,
    [timezone] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO

这个表没有主键,因为区域列可能是null,所以我还没有使用主键。

所以我想在 timezone 列上添加一个非聚集索引,以提高它的性能。

【问题讨论】:

    标签: non-clustered-index


    【解决方案1】:

    简短回答:索引可能会为您提高性能。

    更长的答案。 即使只有这么多的记录,您也可以通过精心挑选的索引看到查询改进。假设此表用于连接,您可能会看到通过该表连接的查询计划中的更改(改进),这可能会给您带来比您预期的更大的好处。

    您似乎给人的印象是您希望索引“一”列。仅索引一列可能不是最佳解决方案。 “覆盖”索引通常会是更好的解决方案(Google 为“覆盖索引”)。

    现在,说了这么多,我怀疑最好的性能可能来自聚簇索引的定义方式。您没有说明此表上聚集索引的性质或数据的用途。但是,如果查询几乎总是以相同的方式访问表(例如,WHERE 和 JOIN 子句总是引用相同的列),那么您可能会发现更改聚集索引会带来最大的改进。

    此外,选择索引的部分技巧涉及平衡查询性能与插入/更新性能。如果数据没有变化,你就没有这个挑战。在阅读一般索引调整建议时请记住这一点。

    底线:我怀疑在 WHERE 和 JOIN 子句中使用的列上的聚集索引是答案。考虑列顺序问题。选择性很重要。

    【讨论】:

    • 感谢您的回复我添加了一个真实的示例表以获得更好的方法。
    • 我不知道 [timezone] 是您预期的搜索结果还是搜索条件。例如,“select timezone from tbl_timezones where country = @c and region = @r”建议在 [country,region,timezone] 上使用索引。
    • 是的,这是正确的,但是还有一个非常相似的具有时区的表,并且该表中的选择类似于 [Select x, y from coordinates where timezone = @timezone]
    猜你喜欢
    • 2017-03-06
    • 1970-01-01
    • 2015-02-24
    • 2023-03-23
    • 2022-01-09
    • 1970-01-01
    • 2012-04-30
    • 1970-01-01
    • 2012-05-20
    相关资源
    最近更新 更多