主键ID达到bigint数据类型的限制

DrN*_*uit 6 mysql int primary-key auto-increment bigint

我有一个表定期暴露于大插入和删除(因此在主id列的数字序列中有很大的间隙).它有一个'int'类型的主id列,它被改为'bigint'.尽管有这种变化,但在未来的某个时间点也将不可避免地超出此数据类型的限制(当前使用情况将表明在未来一年左右的情况).

你如何处理这种情况?我想知道(震惊恐怖)我是否甚至需要主键列,因为它在任何查询中都没有以任何明显的方式使用或被其他表引用等等.删除列是一个解决方案吗?或者那种行为会让你厌恶地从mysql社区中被驱逐出去?!

对于自动增量ID,我们已经接近5亿大关.该表在单独的表中保存与文件数据相关联的关键字.每个文件数据行在关键字表中可以有多达30个与之关联的关键字,因此在您不断插入和删除数万个文件后,它们真正开始堆叠.目前,关键字表包含关键字及其关联的文件的ID,因此,如果我删除了当前的主要id列,除了关键字(varchar)和文件id(int)字段之外,没有唯一的标识符,这将是一个可怕的主键.

非常感谢所有的想法/答案/经验/解决方案.

ale*_*het 24

我知道它已经在一年前得到解答,但只是继续对Luc Franken的回答,

如果每秒插入5亿行,则需要大约1173年才能达到BIG INT的限制.所以是的,我认为不要担心


小智 9

如果您不需要该列,因为您有另一个唯一的记录标识符.就像提供的measurement_id或任何甚至是组合键一样:measurement_id + location_id不需要使用自动增量键.如果有可能你没有唯一的钥匙而不是肯定的.

如果我需要一个非常大的自动增量ID怎么办?

你真的确定你有这么多的插入和删除你会达到极限吗?


hak*_*iko 7

如果我们每秒向表中插入 10 万 (100,000) 条记录,则需要 2,924,712 年

如果我们每秒向表中插入 100 万(1,000,000)条记录,则需要 292,471 年

如果我们每秒向表中插入 1000 万(10,000,000)条记录,则需要 29,247 年

如果我们每秒向表中插入 1 亿条记录,则需要 2,925 年

如果我们每秒向表中插入 10 亿条记录,则需要 292 年

所以不用担心