我正在特别考虑 unsigned int。
这是一个实际的例子：当你的身份列达到最大值时你会怎么做？可以使用BigInt（8 字节存储而不是 4 字节存储）或重构应用程序以支持负整数，甚至可以创建自己的规则，如本答案所示；这些选项都不是最优的。
UInt将是一个理想的解决方案，但 SQL Server 不提供它（MySQL 提供）。
我知道无符号数据类型不是 SQL 标准 (SQL-2003) 的一部分，但对我来说仍然是一种浪费。
不包括这些（在 SQL Server 或标准中）的原因是什么？
如果我不得不猜测，我会说他们试图避免类型的扩散。一般来说，无符号整数可以做任何有符号整数不能做的事情。至于您需要一个介于 2147483648 和 4294967296 之间的数字的情况，您可能应该使用 8 字节整数，因为该数字最终也会超过 4294967296。
为此，您可以使用 -2,147,483,648 作为种子值。
Identity(-2147483648, 1)
我在 Microsoft Office 开发中心发现了一个类似的问题。
Jim Hogg（项目经理）的回复对添加 unsigned int 有一些优点和缺点。主要的缺点是实现隐式类型转换的规则成为正确的噩梦。
该请求被关闭为“不会修复”。
它们不支持 SIGNED 和 UNSIGNED 关键字，因为它们不是标准的。在 SQL 标准中，所有数字类型都是有符号的。
UNSIGNED（和 SIGNED，这是默认值）是 MySQL 扩展，可用于在相同的字节数中存储更高的无符号数，并且不允许负数。
在某些情况下，SQL Server 中需要无符号数。例如，可能需要将二进制值的等价物存储为整数。在这种情况下，对于 32 位二进制值，需要使用 64 位 bigint 而不是 32 位 int 数据类型。
将您的数据库设置为具有最小身份 Identity(-2147483648, 1)
然后在加载到您的 .net UInt64 变量时添加 2147483648 。然后 -2147483648 变为 0 -1000000000 变为 1147483648
但是，我同意该数据类型在 99% 的系统中都足够大。如果你真的需要更多，你可以使用一个 GUID——但是，除非你使用下一个连续的 GUID，否则这对索引来说很糟糕。
以 32 位（8 字节）int 为例。32 位 int 的范围是从 -2^31 到 2^31-1。记录您分配的值需要 31 位，而记录值的符号只需要 1 位。
所以你的问题的答案是“不必要的”。即使您分配的每个值都是正数，但每个值仅浪费 1 位。为每个值仅保存 1 位创建新数据类型并不是优化存储空间的好方法。