2

我必须将 2 个新列添加到具有超过 2.5 亿行的表中col1 char(1) NULL。col2 char(1) NULL我必须用1现有 2.5 亿行的值更新这两列。

然后我的 SSIS 包将按增量顺序每天更新表。SSIS 包将使用来自源表的任何内容填充这两列。

由于我必须更新 250M 行，如何快速完成此操作？

谢啦

4

1 回答 1

7

您没有说您使用的 SQL Server 版本。从 SQL Server 2012 开始，添加NOT NULL具有默认值的新列在大多数情况下是即时的：仅更改表元数据，不更新任何行。感谢 Martin Smith 提供的信息。所以在这个版本中，你最好删除并重新创建列。

在以前的版本中，您可以尝试这样的事情：

WHILE 1 = 1 BEGIN
   WITH T AS (
      SELECT TOP (10000) *
      FROM dbo.YourTable
      WHERE
         T.Col1 IS NULL
         AND T.COl2 IS NULL
   )
   UPDATE T
   SET
      T.Col1 = '1',
      T.Col2 = '1'
   ;
   IF @@RowCount < 10000 BREAK; -- a trick to save one iteration most times
END;

这可能需要很长时间才能运行，但好处是它不会长时间锁定表。索引的精确组合和通常的行大小也会影响它的性能。要更新的行数的最佳点永远不会是恒定的。可能是 50,000 或 2,000。我过去曾在像这样的分块操作中尝试过不同的计数，发现 5,000 或 10,000 通常非常接近最佳大小。

根据 SQL Server 的版本（2008 及更高版本），上述查询也可以通过过滤索引受益：

CREATE UNIQUE NONCLUSTERED INDEX IX_YourTable ON dbo.YourTable (ClusteredColumns)
   WHERE Col1 IS NULL AND COl2 IS NULL;

完成后，删除索引。

请注意，如果您已为两个新列指定了默认值，并且NOT NULL它们将在列创建期间添加值 - 之后可以删除默认值：

ALTER TABLE dbo.YourTable ADD Col1 char(1)
   NOT NULL CONSTRAINT DF_YourTable_Col1 DEFAULT ('1');

与在末尾添加NULL列不同，这可以轻松拆分，这可能会花费大量时间，因此在您的 250M 行表上，这可能不是一个选项。

更新解决布莱恩的评论：

  1. 以 10,000 个小批量执行此操作的基本原理是，更新“开销”的负面影响在很大程度上得到了改善。是的，确实，这将是很多活动——但它不会阻塞很长时间，这就是像这样的活动的#1 性能损害效应：长时间阻塞。

  2. 我们对这个查询的锁定潜力有很多了解：一个 UPDATE EXCLUSIVE 锁，并且前面的一点应该将由此产生的任何有害影响降至最低。如果我缺少其他锁定问题，请分享。

  3. 过滤索引很有帮助，因为它只允许读取索引的几页，然后搜索巨型表。由于更新，必须维护过滤索引以删除更新的行，因为它们不再符合条件，这确实增加了更新写入部分的成本。这听起来很糟糕，直到您意识到UPDATE上面批处理的最大部分，没有某种索引，每次都将是一次表扫描。给定 250M 行，这需要与对整个表进行 12,500 次完整扫描相同的资源！！！因此，我使用索引的建议确实有效，并且是手动遍历聚集索引的一种不错且简单的快捷方式。

  4. 对于具有大量写入操作的表来说，它们对表不利的“索引基本法则”在这里不成立。您正在考虑正常的 OLTP 访问模式，其中可以通过查找找到正在更新的行，然后对于写入，表上的每个附加索引确实会产生以前不存在的开销。将此与我之前的解释进行比较。即使过滤后的索引使该UPDATE部分每行占用 5 倍的 I/O（值得怀疑），这仍然是 I/O 减少了 2,500 倍以上！！！.

评估更新对性能的影响很重要，尤其是在表异常繁忙且不断被使用的情况下。如果需要，就像您建议的那样，在非工作时间安排它（如果存在的话）是基本意义。

我的建议中的一个潜在弱点是，在 SQL 2008 及更低版本中，添加过滤索引可能需要很长时间——尽管可能不会，因为它是一个非常窄的索引，并且将以聚集顺序写入（可能使用单次扫描！）。因此，如果创建时间过长，还有一个替代方法：手动遍历聚集索引。这可能看起来像这样：

DECLARE @ClusteredID int = 0; --assume clustered index is a single int column
DECLARE @Updated TABLE (
   ClusteredID int NOT NULL
);

WHILE 1 = 1 BEGIN
   WITH T AS (
      SELECT TOP (10000) *
      FROM dbo.YourTable
      WHERE ClusteredID > @ClusteredID -- the "walking" part
      ORDER BY ClusteredID -- also crucial for "walking"
   )
   UPDATE T
   SET
      T.Col1 = '1',
      T.Col2 = '1'
   OUTPUT Inserted.ClusteredID INTO @Updated
   ;

   IF @@RowCount = 0 BREAK;

   SELECT @ClusteredID = Max(ClusteredID)
   FROM @Updated
   ;

   DELETE @Updated;
END;

你去吧：没有索引，一路搜索，并且只对整个表进行一次有效扫描（处理表变量的开销很小）。如果ClusteredID列是密集填充的，您甚至可以省去表变量，只需在每个循环结束时手动添加 10,000。

您提供了一个更新，您的聚集索引中有 5 列。这是一个更新的脚本，显示您如何适应它：

DECLARE -- Five random data types seeded with guaranteed low values
   @Clustered1 int = 0,
   @Clustered2 int = 0,
   @Clustered3 varchar(10) = '',
   @Clustered4 datetime = '19000101',
   @Clustered5 int = 0
;

DECLARE @Updated TABLE (
   Clustered1 int,
   Clustered2 int,
   Clustered3 varchar(10),
   Clustered4 datetime,
   Clustered5 int
);

WHILE 1 = 1 BEGIN
   WITH T AS (
      SELECT TOP (10000) *
      FROM dbo.YourTable
      WHERE
         Clustered1 > @Clustered1
         OR (
            Clustered1 = @Clustered1
            AND (
               Clustered2 > @Clustered2
               OR (
                  Clustered2 = @Clustered2
                  AND (
                     Clustered3 > @Clustered3
                     OR (
                        Clustered3 = @Clustered3
                        AND (
                           Clustered4 > @Clustered4
                           OR (
                              Clustered4 = @Clustered4
                              AND Clustered5 > @Clustered5
                           )
                        )
                     )
                  )
               )
            )
         )
      ORDER BY
         Clustered1, -- also crucial for "walking"
         Clustered2,
         Clustered3,
         Clustered4,
         Clustered5
   )
   UPDATE T
   SET
      T.Col1 = '1',
      T.Col2 = '1'
   OUTPUT
      Inserted.Clustered1,
      Inserted.Clustered2,
      Inserted.Clustered3,
      Inserted.Clustered4,
      Inserted.Clustered5
   INTO @Updated
   ;

   IF @@RowCount < 10000 BREAK;

   SELECT TOP (1)
     @Clustered1 = Clustered1
     @Clustered2 = Clustered2,
     @Clustered3 = Clustered3,
     @Clustered4 = Clustered4,
     @Clustered5 = Clustered5
   FROM @Updated
   ORDER BY
      Clustered1,
      Clustered2,
      Clustered3,
      Clustered4,
      Clustered5
   ;

   DELETE @Updated;
END;

如果您发现一种特定的方法不起作用，请尝试另一种方法。在更深层次上理解数据库系统将导致更好的想法和更好的解决方案。我知道嵌套很深的WHERE情况很糟糕。你也可以试试下面的大小——这工作完全相同，但更难理解，所以我不能真正推荐它，即使添加额外的列很容易。

WITH T AS (
   SELECT TOP (10000) *
   FROM
      dbo.YourTable T
   WHERE
      122 <=
         CASE WHEN Clustered1 > @Clustered1 THEN 172 WHEN Clustered1 = @Clustered1 THEN 81 ELSE 0 END
         + CASE WHEN Clustered2 > @Clustered2 THEN 54 WHEN Clustered1 = @Clustered2 THEN 27 ELSE 0 END
         + CASE WHEN Clustered3 > @Clustered3 THEN 18 WHEN Clustered3 = @Clustered3 THEN 9 ELSE 0 END
         + CASE WHEN Clustered4 > @Clustered4 THEN 6 WHEN Clustered4 = @Clustered4 THEN 3 ELSE 0 END
         + CASE WHEN Clustered5 > @Clustered5 THEN 2 WHEN Clustered5 = @Clustered5 THEN 1 ELSE 0 END
   ORDER BY
      Clustered1, -- also crucial for "walking"
      Clustered2,
      Clustered3,
      Clustered4,
      Clustered5
)
UPDATE T
SET
   T.Col1 = '1',
   T.Col2 = '1'
OUTPUT
   Inserted.Clustered1,
   Inserted.Clustered2,
   Inserted.Clustered3,
   Inserted.Clustered4,
   Inserted.Clustered5
INTO @Updated
;

我已经多次使用这种精确的“小批量遍历聚集索引”策略对巨大的表执行更新，而不会对生产数据库产生不良影响。

于 2013-06-21T21:14:05.230 回答