c# - 编程夜间数据传输的最佳方式，身份列高

Question

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

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

• 方法A:每天晚上我删除所有之前导入的行，并做一个完整的重新导入，这种方法成本高，但易于编程、维护，整体健壮

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

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

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

Answer 1

will there eventually be a performance hit

我不明白为什么应该有。字段的大小相同(比如 32 位)，因此无论字段的值是 10 还是 2,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 慢，因为它的大小是它的两倍，而且服务器必须将两倍的字节读/写到磁盘并使用两倍的内存。

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

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