Answers:
通常,您将使用整数而不是varchar,因为它们占用较少的空间,并且具有很好理解的排序模式可以快速建立索引等。整数是CPU的自然数据类型,因此性能通常是最佳的。通常,整数是4个字节,相当于(非Unicode)varchar中的4个字符。
如果您担心INT类型的空间不足,请尝试使用BIGINT,它会为您提供8字节的数字。这方面的限制是非常巨大的,并且在达到该记录限制之前,您可能会用完磁盘空间:-) BIGINT的性能也将非常好,尤其是现在许多服务器也是64位的。
关于在INT中用尽时会发生什么的问题的第一部分的答案并不简单,尤其是正如您所说的那样,没有将数据类型更改为BIGINT。基本上没有什么可以做的,并且您可能能够做的事情在很大程度上受到数据库中数据性质的限制。哪些记录是该数据的外键?您还需要该表和相关记录中的所有数据吗?假设您可以存档许多初始数据(及其相关数据),那么我唯一建议的就是将数据移出表(假设前1条到X百万条记录),然后将身份种子重置为1。尽管我不推荐这样做,但有各种各样的原因-例如,我看到很多代码都在执行诸如检查id字段的最大值,看看刚刚添加了什么,那是行不通的(不应该这样做)。同样,人们认为记录N是在N + 1之前创建的。我认为没有简单的答案。
最后,我不了解MySQL,但是如果达到极限,SQL Server会给出溢出错误。
一个被忽视的观点是,许多人从1开始自动编号或身份,因此立即失去了可能范围的一半(对于带符号)
您只需将数字重新定义为从-1开始,在这种情况下以-1递增。
可以说,如果您曾经希望填写身份列,那么您应该在其中进行设计并在开始时使用更广泛的数据类型。
请参阅以下最新问题:SQL Server 2008:如果身份超过最大整数值会发生什么?
溢出BIGINT?哈哈。首先弄清楚如何实现永生。INT UNSIGNED(40亿)很难达到。一年内每秒100 INSERT将接近INT溢出。BIGINT将花费数十亿年。
要修复:ALTER TABLE foo MODIFY COLUMN id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT; 但这将花费数小时,因为它将复制整个表(有近40亿行,对吗?)并重建所有二级索引。未雨绸缪。
通常,当您尝试为字段存储太大的数字时(例如,在TINYINT UNSIGNED中为999),它将无提示地将其限制为该字段的最大值(在这种情况下为255)。可能会有“警告”,但是大多数人都不会去检查警告。如果它是UNIQUE字段,或者有FOREIGN KEYS,则可能会出现更严重的错误。
CHAR或VARCHAR被静默截断为可用空间。