sql-server – 为什么在列大小增加后创建索引需要更长的时间？

我们的供给商险些在整个数据库的每一列上都变动了列宽.该数据库约莫有7TB,9000个表.我们正在实行在具有55亿行的表上建设索引.在供给商进级之前,我们可以在2小时内建设索引.此刻必要几天时刻.他们所做的是将任何varchar(xx)巨细增进到varchar(256).以是大大都列已往都是varchar(18)或varchar(75)等.

无论怎样,主键由6列构成,组合宽度为126个字符.此刻进级后,主键为1283个字符,违背了SQL Server限定为900个字符.整个表的列宽从总组合varchar计数1049变为总组合varchar计数4009.

数据没有增进,表格不会占用比全部列宽增进之前更多的“空间”,可是建设像索引一样简朴的示意此刻耗费了不公道的时刻.

任何人都可以表明为什么建设和索引必要耗费更长的时刻来完成独一的工作就是增进列的巨细？

我们实行建设的索引长短聚簇的,由于pk是聚簇索引.在多次实行建设索引后,我们放弃了.我以为它没有完成绩运行了4到5天.

我通过获取文件体系快照并在更宁静的处事器上启动数据库,在非出产情形中实行了这一点.

办理要领

我试图做更多的研究,以扩展他的谜底中的“从事物级联”这一部门.我没有完备或简明的表明,但这是我找到的.

Repro剧本

I created a full script天生一个假数据集,在我的呆板上,VARCHAR(256)版本的索引建设约莫必要10倍.行使的数据完全沟通,但第一个表行使现实的最大长度18,75,9,15,123和5,而全部列在第二个表中行使最大长度256.

键入原始表

在这里,我们看到原始查询在约莫20秒内完成,逻辑读取便是~1.5GB的表巨细(195K页,每页8K).

-- CPU time = 37674 ms,elapsed time = 19206 ms.
-- Table 'testVarchar'. Scan count 9,logical reads 194490,physical reads 0
CREATE CLUSTERED INDEX IX_testVarchar
ON dbo.testVarchar (s1,s2,s3,s4)
WITH (MAXDOP = 8) -- Same as my global MAXDOP,but just being explicit
GO

键入VARCHAR(256)表

对付VARCHAR(256)表,我们看到颠末的时刻已经大大增进.

风趣的是,CPU时刻和逻辑读取都没有增进.这是有原理的,由于该表具有完全沟通的数据,但它不能表明为什么颠末的时刻要慢得多.

-- CPU time = 33212 ms,elapsed time = 263134 ms.
-- Table 'testVarchar256'. Scan count 9,logical reads 194491
CREATE CLUSTERED INDEX IX_testVarchar256
ON dbo.testVarchar256 (s1,but just being explicit
GO

I / O和守候统计：原始

假如我们捕捉更多细节(行使p_perfMon,a procedure that I wrote),我们可以看到绝大大都I / O都是在LOG文件上执行的.我们在现实的ROWS(主数据文件)上看到相对适度的I / O量,首要的守候范例是LATCH_EX,暗示内存中的页面争用.

我们还可以看到我的旋转磁盘介于“坏”和“令人震惊的坏”之间,according to Paul Randal

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!