对夜间数据传输进行编程的最佳方式，身份列运行高

本文关键字：方式 身份 运行 最佳 数据传输 编程 | 更新日期: 2023-09-27 18:34:14

我正在编写一个应用程序，该应用程序每晚都需要将自己的数据库与另一个数据库同步。当数据被拉过来时，它也以相当复杂的方式进行编程转换。

现在我看到了两种可能的方法：

  • 方法A：每天晚上我都会删除所有以前导入的行，并进行完全重新导入，此方法价格昂贵，但易于编程，维护，整体健壮

  • 方法 B：我为每个导入的行保存对原始数据的引用，如果数据分别是新的、更改的或删除的，则进行插入、更新或删除(单独保留引用非常复杂，因为没有简单的一对一关系(

显然，方法 B 更复杂，可能更容易导致错误，所以我更喜欢使用方法 A。但是，由于每晚插入大约 100,000 行，因此标识列将随着时间的推移而运行得非常高。每晚简单地重置为 1 不是一种选择，因为导入的行实际上与与数据传输无关的其他行混合，最后一组行必须不受传输的影响。

我对此的主要问题是，我们的身份专栏是否会高位运行(每年增加约3600万(。它并不整洁，但最终会受到性能影响吗，如果我们达到最大的 int 值会发生什么？有没有人面临类似的挑战，可以分享他们的经验？

对夜间数据传输进行编程的最佳方式，身份列运行高

最终会有性能打击吗

我不明白为什么应该有。字段的大小相同(例如，32 位(，因此无论字段的值是 10 还是 2,000,000,000,000,000，它的所有操作都将以相同的速度执行。

如果您的标识列是 int(32 位(，那么它将持续 2,147,483,647 / 36,000,000 = 59 年。

很容易检查当您达到最大值 2,147,483,647 时会发生什么。在 tempdb 中创建表。(我正在使用SQL Server 2008进行此测试(。

USE [tempdb]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[BigTable](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [Data] [int] NOT NULL,
 CONSTRAINT [PK_BigTable] 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]
GO

将标识设置为高值：

USE [tempdb]
GO
DBCC CHECKIDENT ("[dbo].[BigTable]", RESEED, 2147483645);

尝试插入 10 行：

USE [tempdb]
GO
INSERT INTO [dbo].[BigTable]
([Data])
VALUES
(0)
GO 10

这是我在输出窗口中得到的：

Beginning execution loop
(1 row(s) affected)
(1 row(s) affected)
(1 row(s) affected)
Msg 8115, Level 16, State 1, Line 2
Arithmetic overflow error converting IDENTITY to data type int.
Arithmetic overflow occurred.
** An error was encountered during execution of batch. Continuing.
Msg 8115, Level 16, State 1, Line 2
Arithmetic overflow error converting IDENTITY to data type int.
Arithmetic overflow occurred.
** An error was encountered during execution of batch. Continuing.
Msg 8115, Level 16, State 1, Line 2
Arithmetic overflow error converting IDENTITY to data type int.
Arithmetic overflow occurred.
** An error was encountered during execution of batch. Continuing.
Msg 8115, Level 16, State 1, Line 2
Arithmetic overflow error converting IDENTITY to data type int.
Arithmetic overflow occurred.
** An error was encountered during execution of batch. Continuing.
Msg 8115, Level 16, State 1, Line 2
Arithmetic overflow error converting IDENTITY to data type int.
Arithmetic overflow occurred.
** An error was encountered during execution of batch. Continuing.
Msg 8115, Level 16, State 1, Line 2
Arithmetic overflow error converting IDENTITY to data type int.
Arithmetic overflow occurred.
** An error was encountered during execution of batch. Continuing.
Msg 8115, Level 16, State 1, Line 2
Arithmetic overflow error converting IDENTITY to data type int.
Arithmetic overflow occurred.
** An error was encountered during execution of batch. Continuing.
Batch execution completed 10 times.

结果如下：

USE [tempdb]
GO
SELECT [ID] ,[Data]
FROM [dbo].[BigTable]
GO

ID  Data
2147483645  0
2147483646  0
2147483647  0

DBCC CHECKIDENT ("[tempdb].[dbo].[BigTable]", NORESEED);
Checking identity information: current identity value '2147483647', current column value '2147483647'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

所以，是的，当你用尽所有 int 值时会出现问题。你可以改用 bigint。它是 64 位(8 字节，而不是 16 字节(，使用寿命更长：9,223,372,036,854,775,807 / 36,000,000 = 256,204,778,801 年bigint 的性能与 64 位计算机上的 int 几乎相同。它可能比 int 慢，因为它的大小是它的两倍，并且服务器必须向磁盘读取/写入两次字节并使用两次内存量。

在性能方面，真正重要的是在删除大量行并向表添加大量行后重建索引并更新表上的统计信息，因为所有统计信息都会严重倾斜。这里我指的是使用此表的系统其余部分的性能，而不是删除和添加行的过程。

若要提高删除大量行并添加大量行的夜间同步过程的性能，请考虑在更改之前禁用表上的所有索引，并在更改后重新启用(通过重新生成(它们。

只要您的身份是 64 位 int 或更好，您就可以管理。这并不理想，但它会工作几年，直到你决定你真的需要真正的 refator。

是的，您可以构建一个理想的解决方案，但听起来您现在需要一个"足够好"的解决方案......这就是方法A。

相关文章：