在 sql server 中更新大表中的行
Tuf*_*and 0 performance sql-server update query-performance
我想更新一个有 83,423,460 行并且还在增长的大表。
以下查询需要 8 分钟才能成功执行：
UPDATE FPP_Invoice_Revenue
SET Till_Prev_Inv_Amt = Till_Prev_Inv_Amt_In_USD / 0.0285714286,
Cur_Inv_Amt = Cur_Inv_Amt_In_USD / 0.0285714286,
YTD_Inv_Amt = YTD_Inv_Amt_In_USD / 0.0285714286
WHERE SOW_Number = '20014378'
存在一个clustered index。我想在更新之前禁用该索引，并在更新后再次重建，但这也不起作用，因为重建需要很多时间。
我在某处读过这可以通过分成小部分来实现，但是如何划分上述查询？
DDL：
CREATE TABLE [dbo].[FPP_Invoice_Revenue](
[Project_Code] [varchar](10) NOT NULL,
[Project_Desc] [varchar](50) NULL,
[SOW_Number] [varchar](10) NOT NULL,
[SOW_Desc] [varchar](50) NULL,
[Invoice_No] [varchar](50) NOT NULL,
[Inv_Month] [int] NOT NULL,
[Inv_Year] [int] NOT NULL,
[Billing_Date] [smalldatetime] NULL,
[Doc_Currency] [varchar](10) NULL,
[Vertical] [varchar](255) NULL,
[Till_Prev_Inv_Amt] [numeric](24, 10) NULL,
[Cur_Inv_Amt] [numeric](24, 10) NULL,
[YTD_Inv_Amt] [numeric](24, 10) NULL,
[Till_Prev_Inv_Amt_In_USD] [numeric](24, 10) NULL,
[Cur_Inv_Amt_In_USD] [numeric](24, 10) NULL,
[YTD_Inv_Amt_In_USD] [numeric](24, 10) NULL,
CONSTRAINT [PK_FPP_Invoice_Revenue] PRIMARY KEY CLUSTERED
(
[Project_Code] ASC,
[SOW_Number] ASC,
[Invoice_No] ASC,
[Inv_Month] ASC,
[Inv_Year] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF,
ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF
GO
执行计划：
Han*_*non 12
添加索引SOW_Number将允许 SQL Server 非常快速地识别需要更新的行，而无需扫描整个表（假设与WHERE子句匹配的行数相对较少，从而使索引具有高度选择性）。
CREATE NONCLUSTERED INDEX IX_SOW_Number
ON dbo.FPP_Temp_Revenue(SOW_Number)
INCLUDE (
Till_Prev_Inv_Amt_In_USD
, Cur_Inv_Amt_In_USD
, YTD_Inv_Amt_In_USD
);
即使您已SOW_Number定义为聚集索引的一部分，它也不是索引的前导列，这意味着 SQL Server 必须扫描整个索引以查找满足该WHERE子句的行。添加INCLUDE子句中列出的三列将允许 SQL Server 不对这些值执行对聚集索引的查找，否则在SET子句中的计算中需要这样做。
如果不仔细评估工作量，我通常不会建议添加这样的索引；但是我假设您除了在脚本中标识的聚集索引之外没有任何索引。在这种情况下添加单个索引很可能会对更新的性能产生非常大的影响，而不会显着影响工作负载的其他部分。
我在我的笔记本电脑上设置了一个测试台，所以我可以测试添加建议索引与没有索引的性能SOW_Number。
首先，我TestDB为此测试创建了一个新数据库（我在 Linux RC3 上使用 SQL Server）：
USE master;
IF EXISTS (SELECT 1 FROM sys.databases d WHERE d.name = 'TestDB')
DROP DATABASE TestDB;
GO
CREATE DATABASE TestDB
ON (NAME = 'TestDB_Primary', FILENAME = '/var/opt/mssql/data/TestDB_Primary.mdf', SIZE = 5GB, MAXSIZE = 10GB, FILEGROWTH = 1GB)
LOG ON (NAME = 'TestDB_Log', FILENAME = '/var/opt/mssql/log/TestDB_Log.ldf', SIZE = 5GB, MAXSIZE = 10GB, FILEGROWTH = 1GB);
GO
USE TestDB;
CREATE TABLE dbo.FPP_Invoice_Revenue(
Project_Code varchar(10) NOT NULL
, Project_Desc varchar(50) NULL
, SOW_Number varchar(10) NOT NULL
, SOW_Desc varchar(50) NULL
, Invoice_No varchar(50) NOT NULL
, Inv_Month int NOT NULL
, Inv_Year int NOT NULL
, Billing_Date smalldatetime NULL
, Doc_Currency varchar(10) NULL
, Vertical varchar(255) NULL
, Till_Prev_Inv_Amt numeric(24, 10) NULL
, Cur_Inv_Amt numeric(24, 10) NULL
, YTD_Inv_Amt numeric(24, 10) NULL
, Till_Prev_Inv_Amt_In_USD numeric(24, 10) NULL
, Cur_Inv_Amt_In_USD numeric(24, 10) NULL
, YTD_Inv_Amt_In_USD numeric(24, 10) NULL
CONSTRAINT PK_FPP_Invoice_Revenue PRIMARY KEY CLUSTERED
(
Project_Code ASC
, SOW_Number ASC
, Invoice_No ASC
, Inv_Month ASC
, Inv_Year ASC
) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF,
ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
) ON [PRIMARY];
GO
接下来，我插入了 10,000,000 行以获得足够大的表。我知道，这比你的表小一点，但它提供了足够的数据来进行合理的推断：
TRUNCATE TABLE dbo.FPP_Invoice_Revenue;
;WITH v AS (
SELECT v.num
FROM (VALUES (0), (1), (2), (3), (4), (5), (6), (7), (8), (9))v(num)
)
INSERT INTO dbo.FPP_Invoice_Revenue
SELECT Project_Code = CONVERT(varchar(10), ROW_NUMBER() OVER (ORDER BY v1.num, v2.num))
, Project_Desc = CONVERT(varchar(50), CRYPT_GEN_RANDOM(50))
, SOW_Number = v5.num /* only 10 distinct values */
, SOW_Desc = CONVERT(varchar(50), CRYPT_GEN_RANDOM(50))
, Invoice_No = CONVERT(varchar(50), CRYPT_GEN_RANDOM(50))
, Inv_Month = ROW_NUMBER() OVER (ORDER BY v1.num, v2.num) % 12
, Inv_Year = 2009 + ROW_NUMBER() OVER (ORDER BY v1.num, v2.num) % 8
, Billing_Date = DATEFROMPARTS(2009 + ROW_NUMBER() OVER (ORDER BY v1.num, v2.num) % 8, 1, (ROW_NUMBER() OVER (ORDER BY v1.num, v2.num) % 12) + 1)
, Doc_Currency = CONVERT(varchar(10), CRYPT_GEN_RANDOM(10))
, Vertical = CONVERT(varchar(255), CRYPT_GEN_RANDOM(255))
, Till_Prev_Inv_Amt = CONVERT(numeric(24, 10), 1)
, Cur_Inv_Amt = CONVERT(numeric(24, 10), 2)
, YTD_Inv_Amt = CONVERT(numeric(24, 10), 3)
, Till_Prev_Inv_Amt_USD = CONVERT(numeric(24, 10), 4)
, Cur_Inv_Amt_In_USD = CONVERT(numeric(24, 10), 5)
, YTD_Inv_Amt_In_USD = CONVERT(numeric(24, 10), 6)
FROM v v1 --10 rows
CROSS JOIN v v2 --100 rows
CROSS JOIN v v3 --1000 rows
CROSS JOIN v v4 --10000 rows
CROSS JOIN v v5 --100000 rows
CROSS JOIN v v6 --1000000 rows
CROSS JOIN v v7;--10000000 rows
接下来，我创建上面建议的非聚集索引：
CREATE NONCLUSTERED INDEX IX_SOW_Number
ON dbo.FPP_Invoice_Revenue(SOW_Number)
INCLUDE (Till_Prev_Inv_Amt, Cur_Inv_Amt, YTD_Inv_Amt);
这花了大约 1:20 在我的笔记本电脑上创建。
现在，查询：
UPDATE dbo.FPP_Invoice_Revenue
SET Till_Prev_Inv_Amt_In_USD = Till_Prev_Inv_Amt / 0.0285
, Cur_Inv_Amt_In_USD = Cur_Inv_Amt / 0.0285
, YTD_Inv_Amt_In_USD = YTD_Inv_Amt / 0.0285
WHERE SOW_Number = '6';
测试数据均匀分布在 10 个SOW_Number值上；WHERE SOW_Number = '6'表示我们将更新 1,000,000 行：
（1000000 行受影响）
更新查询的实际执行计划：
这个的执行统计：
SQL Server 解析和编译时间：
CPU 时间 = 0 毫秒，已用时间 = 0 毫秒。
表“FPP_Invoice_Revenue”。扫描计数1，逻辑读6567261，物理读8920，预读209603，lob逻辑读0，lob物理读0，lob预读0。（1000000 行受影响）
SQL Server 执行时间：
CPU 时间 = 9376 毫秒，已用时间 = 13689 毫秒。
从上面可以看出，查询只用了大约 14 秒就更新了 1,000,000 行。如果SOW_Number更具选择性，所需的时间将成比例地减少。
正如您在问题中所确定的那样，删除聚集索引无助于提高更新查询的性能。了解具有聚集索引的表中的所有数据实际上都存储在聚集索引中。删除并重新创建聚集索引将导致在数据移入和移出聚集索引时将所有 8300 万行写入日志。这是许多额外的 I/O，对于更新成功来说是不必要的。
您已SOW_Number定义为varchar(10); 如果该列的内容实际上总是 10 个字符长，您可能会考虑将其修改为 achar(10)而不是varchar(10)，因为这实际上更有效。对于varchar您拥有的所有列，请考虑这一点。另外，Vertical实际上是否需要 255 个字符长？据推测，Inv_Month而Inv_Year实际上并不需要存储多达2,147,483,647？您可能会将这些列转换为smallint每行并节省 4 个字节。请记住，聚集索引键中的列在每个非聚集索引中都使用（复制），通过调整数据大小节省的空间可能会很大。
| 归档时间： |
|
| 查看次数： |
24579 次 |
| 最近记录： |