在我当前的项目中，我遇到了我们的主数据库脚本。仔细看一下，我注意到我们所有的原始主键的数据类型都是numeric(38,0) 我们目前正在运行 SQL Server 2005 作为我们的主要数据库平台。
对于一点上下文，我们支持 Oracle 和 SQL Server 作为我们的后端。在 Oracle 中，我们的主键的数据类型为number(38,0)。
有人知道这种实施可能产生的副作用和性能影响吗？我一直提倡并实现int或bigint作为主键，并且很想知道 numeric(38,0) 是否是更好的选择。
好吧，您正在花费更多数据来存储您永远无法真正达到的数字。
bigint 在 8 个字节内上升到 9,223,372,036,854,775,807
int 在 4 个字节中上升到 2,147,483,647
如果我做对了，一个 NUMERIC(38,0) 将占用 17 个字节。
差别不大，但是：较小的数据类型 = 内存中的更多行（或相同行数的更少页面）= 更少的磁盘 I/O 进行查找（索引或数据页面查找）。复制、日志页面等也是如此。
对于 SQL Server：INT 是 IEEE 标准，因此 CPU 比较容易比较，因此使用 INT 与 NUMERIC（压缩十进制格式）相比，性能略有提高。（注意在 Oracle 中，如果当前版本与我长大的旧版本相匹配，所有数据类型都会被打包，因此内部的 INT 与 NUMERIC(x,0) 几乎相同，因此没有性能差异）
所以，从总体上来说——如果你有很多磁盘、RAM 和备用 I/O，那么就使用你想要的任何数据类型。如果您想获得更多性能，请保守一点。
否则在这一点上，我会保持原样。没有必要改变事情。
除非考虑到存储方面的考虑和未来 DBA 的一些初步困惑，否则我认为 NUMERIC(38,0) 不是一个坏主意。您的表中最多允许 9.99 x 10^38 条记录，您肯定永远无法达到。我快速深入研究并没有发现任何不使用它的明显理由。我怀疑您唯一的潜在问题将是它所消耗的存储空间，但鉴于存储空间如此便宜，这应该不是问题。
我在 Oracle 数据库中看到过很多次，因为它是一个相当大的默认值，您在创建表时不需要考虑它，类似于在 SQL Server 中默认使用 INT 或 BIGINT。
这太大了，因为您永远不会有那么多行。更大的尺寸将导致更多的存储空间。这本身并不是什么大问题，但也意味着更多的磁盘读取以从表或索引中检索数据。这将意味着更少的行将适合数据库服务器上的内存。
我认为它的损坏程度不足以修复它。
You'd be better off using a GUID. Really. The normal reason not to use one is that an integer performs better. But GUID is smaller than numeric(38), and has the added benefit of making it a little easier to do thing like let disconnected users create and sync new records.