SQL Server 系统表标识 crysis / SYSOBJECTS 表 ID 接近 int 最大值答案

【问题标题】：SQL Server system table identity crysis / SYSOBJECTS table ID is close to int max valueSQL Server 系统表标识 crysis / SYSOBJECTS 表 ID 接近 int 最大值
【发布时间】：2020-04-27 01:11:30
【问题描述】：

SYSOBJECTS 表有一个 int 类型的标识列。但是 ID 列中的值越来越接近 int 最大值。我想当它达到最大值时将无法创建任何对象。

例如，有没有办法改变该表以将 ID 列转换为 BIGINT？或者有什么工具可以解决这个问题？

【问题讨论】：

我不禁觉得这是在问错误的问题......为什么这个神秘的数据库中有（或总共有）近 240 万个对象？
你不能改变系统表的定义，即使你可以，其余的引擎和系统对象也不知道你做了，所以根本行不通。请记住，创建的对象的限制是 2^31-1 -- 21 十亿个对象 -- 你确定你已经接近了吗？如果您的数据库已经成功实现了这一目标，那么您应该使用全新的数据库和数据转换进行重新设计，这也将解决重置身份的问题。
这是一个非常古老的数据库，经过多次部署。每次部署都会删除并再次创建一些视图/过程，因此 id 会递增。
我们那里没有那么多对象。这都是因为没有最佳的部署过程。
对象 id 不是按顺序分配的，所以可能不需要恐慌它们有很大的增量（16000057）并在溢出时环绕

标签： sql-server system-tables

【解决方案1】：

您无需担心。

对象 ID 不是按顺序分配的。它们之间有 16000057 的间隙，并且只是在溢出时环绕（大约每隔几百个对象创建）所以你会在那里看到一些大数字是正常的。

【讨论】：

谢谢，但我找不到有关如何为系统表分配这些 id 以及它如何在溢出时工作的任何信息。也许你有一些文档参考？
除了可能在某处告诉您不要为对象 ID 分配任何含义的东西之外，不会有任何关于此的文档。当然 16000057 和 wrap around 是一个内部实现细节，只需创建一些对象即可轻松测试，但不会记录在案
刚刚创建了两个相似的表并获得了 19543899 和 35543956 之类的 ID。所以你是对的，没有什么可担心的 :)
顺便说一句，16000057 是大于 16000000 的最小素数。这不太可能是巧合，并且可能选择与哈希函数配合使用，例如可能在内部用于内存中的哈希表支持系统表。

【解决方案2】：

这不适合（很好）在评论中。

来自Maximum Capacity Specifications for SQL Server：

SQL Server Database | Maximum sizes/numbers | Additional Information 
Engine object       | SQL Server (64-bit)   |
--------------------|-----------------------|----------------------------------------------------
Tables per database | Limited by number of  | Database objects include objects such as tables,
                    | objects in a database | views, stored procedures, user-defined functions,
                    |                       | triggers, rules, defaults, and constraints.
                    |                       | The sum of the number of all objects in a database
                    |                       | cannot exceed 2,147,483,647.

如果您接近 2,147,483,647 个对象，则需要修复您的设计。故事结束。

【讨论】：

我们没有那么多对象。问题是它们被多次重新创建并增加了 id。
是的，后来在 cmets @SergB 中透露了这一点；到那时我已经回答/回答了这个问题。