SQL性能建议

Question

我知道，这可能是一个棘手的问题，它在很大程度上取决于环境。

我有一个包含大约1000万行(每行包含4个varchar)的表。在用于where的字段( varchar)上有一个非聚集索引。

我有点困惑，因为在索引列上使用where来选择一行时，大约需要一秒的时间才能结束。

有什么建议可以改善这个响应时间吗？在这里，索引集群是一个很好的解决方案吗？

以下是表的定义：

CREATE TABLE [dbo].[MYTABLE](
[ID] [uniqueidentifier] NOT NULL DEFAULT (newid()),
[CreationDate] [datetime] NOT NULL DEFAULT (getdate()),
[UpdateDate] [datetime] NULL,
[FIELD1] [varchar](9) NOT NULL,
[FIELD2] [varchar](max) NOT NULL,
[FIELD3] [varchar](1) NULL,
[FIELD4] [varchar](4) NOT NULL,
CONSTRAINT [PK_MYTABLE] PRIMARY KEY CLUSTERED 
(
[ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

以下是索引定义：

CREATE UNIQUE NONCLUSTERED INDEX [IX_FIELD1] ON [dbo].[MYTABLE]
(
[FIELD1] 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)

下面是我使用的查询(非常基本)：

SELECT * FROM MYTABLE WHERE FIELD1 = 'DATA'

Answer 1

在这种情况下，由于选择了所有列(*)，因此将非聚集索引更改为聚集索引将缩短时间，因为从非聚集索引访问其他列(未包含在索引中，也不包括在索引中，也不按INCLUDE排序)将需要使用实际数据检索另一个页面。

由于每个表的聚集索引不能超过一个，所以必须删除现有索引(在本例中为PRIMARY KEY )，然后创建它。

ALTER TABLE dbo.MYTABLE DROP [PK_MYTABLE] -- This might fail if you have foreign keys

ALTER TABLE dbo.MYTABLE ADD CONSTRAINT PK_MYTABLE PRIMARY KEY NONCLUSTERED (ID) 

DROP INDEX [IX_FIELD1] ON [dbo].[MYTABLE]

CREATE CLUSTERED INDEX [IX_FIELD1] ON [dbo].[MYTABLE] (FIELD1)

索引访问时间也可能因其碎片而有很大的差异(如果有许多插入、删除或更新的值不大于或低于前一个/第一个)。

还请记住，如果您正在执行其他操作，如联接、函数调用或附加的WHERE过滤器，则引擎可能决定不使用这些索引。

Answer 2

如果确定WHERE子句中使用的列是唯一的，则可以在该列上创建唯一聚类索引。

如果该列中的值不是唯一的，则可以实现覆盖指数。例如，如果您有这个索引：

CREATE NONCLUSTERED INDEX IX_Column4 ON MyTable(Column4)
INCLUDE (Column1, Column2);

执行下列查询时：

SELECT Column1, Column2 FROM MyTable WHERE Column4 LIKE 'Something';

您将(很可能)使用IX_Column4索引。但在执行以下内容时：

SELECT Column1, Column2, Column3 FROM MyTable WHERE Column4 LIKE 'Something';

你将不会受益于这种指数所提供的优势。

如果表中的行是反式INSERTED, DELETED or UPDATED，则应检查它们是否为索引碎片和重建或重新组织。

如果您想了解更多关于索引的内容，我推荐以下文章：

• 可用索引类型，查看为各种索引提供的指南。
• Server索引设计指南

希望能帮上忙。