插入时的索引性能
Index performance while doing insert
我有一个有 4 列的 table,我有 3 个索引 table:
CREATE TABLE [dbo].CustomerInfo(
ID [int] IDENTITY(1,1) NOT NULL,
UserHashID [varchar](20) NOT NULL,
ShippingID [int] NOT NULL,
Received [bit] NOT NULL,
CONSTRAINT [PK_ID] 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]
CREATE NONCLUSTERED INDEX [IDX_CustomerInfo_ShippingID] ON [dbo].[CustomerInfo] ( [ShippingID] 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]
CREATE NONCLUSTERED INDEX [IDX_CustomerInfo_UserHashID] ON [dbo].[CustomerInfo] ( [UserHashID] 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]
CREATE NONCLUSTERED INDEX [IDX_CustomerInfo_UserHashIDShippingID] ON [dbo].[CustomerInfo] ( [UserHashID] ASC, [ShippingID] 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]
我正在插入大约 4-5 百万条记录,这个过程大约需要 45 分钟。我意识到如果我删除索引,插入会更快(2-3 分钟)。
想知道删除索引、执行插入并在插入完成后重建索引是否有任何副作用。整个过程可能需要 5 分钟,如果启用索引则需要 45 分钟。
不,删除索引、执行插入并在插入完成后重新构建索引没有副作用(假设在执行插入时没有其他需要访问 table) .
这是一个很常见的模式。
[总而言之,我对具有 4 列和 3 个索引的 table 的时差感到惊讶。你能post你的模式和索引定义吗]
正如@PJ8912 所指出的,事务日志记录可能会有所不同,具体取决于您备份事务日志的频率。
更新:无关,但是这个索引
CREATE NONCLUSTERED INDEX [IDX_CustomerInfo_UserHashID]
ON [dbo].[CustomerInfo] ([UserHashID] ASC)
是多余的,因为它包含在这个索引中:
CREATE NONCLUSTERED INDEX [IDX_CustomerInfo_UserHashIDShippingID]
ON [dbo].[CustomerInfo] ([UserHashID] ASC, [ShippingID] ASC)
根据事务日志记录的级别,TLog 可能会因定期重新创建索引而填满。如果您截断索引以消除它们,则不会记录该操作。
创建新索引后,执行计划的统计信息可能不是最新的。您可能希望使用 FULL SCAN 模式更新统计数据。
我有一个有 4 列的 table,我有 3 个索引 table:
CREATE TABLE [dbo].CustomerInfo(
ID [int] IDENTITY(1,1) NOT NULL,
UserHashID [varchar](20) NOT NULL,
ShippingID [int] NOT NULL,
Received [bit] NOT NULL,
CONSTRAINT [PK_ID] 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]
CREATE NONCLUSTERED INDEX [IDX_CustomerInfo_ShippingID] ON [dbo].[CustomerInfo] ( [ShippingID] 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]
CREATE NONCLUSTERED INDEX [IDX_CustomerInfo_UserHashID] ON [dbo].[CustomerInfo] ( [UserHashID] 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]
CREATE NONCLUSTERED INDEX [IDX_CustomerInfo_UserHashIDShippingID] ON [dbo].[CustomerInfo] ( [UserHashID] ASC, [ShippingID] 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]
我正在插入大约 4-5 百万条记录,这个过程大约需要 45 分钟。我意识到如果我删除索引,插入会更快(2-3 分钟)。
想知道删除索引、执行插入并在插入完成后重建索引是否有任何副作用。整个过程可能需要 5 分钟,如果启用索引则需要 45 分钟。
不,删除索引、执行插入并在插入完成后重新构建索引没有副作用(假设在执行插入时没有其他需要访问 table) .
这是一个很常见的模式。
[总而言之,我对具有 4 列和 3 个索引的 table 的时差感到惊讶。你能post你的模式和索引定义吗]
正如@PJ8912 所指出的,事务日志记录可能会有所不同,具体取决于您备份事务日志的频率。
更新:无关,但是这个索引
CREATE NONCLUSTERED INDEX [IDX_CustomerInfo_UserHashID]
ON [dbo].[CustomerInfo] ([UserHashID] ASC)
是多余的,因为它包含在这个索引中:
CREATE NONCLUSTERED INDEX [IDX_CustomerInfo_UserHashIDShippingID]
ON [dbo].[CustomerInfo] ([UserHashID] ASC, [ShippingID] ASC)
根据事务日志记录的级别,TLog 可能会因定期重新创建索引而填满。如果您截断索引以消除它们,则不会记录该操作。
创建新索引后,执行计划的统计信息可能不是最新的。您可能希望使用 FULL SCAN 模式更新统计数据。