我遇到过这样一个事实:有些人在从表中删除行之后,还会重置该表主键列的自动增量,以便对所有值重新编号,就好像它们再次从1开始一样(或者不管初始起点是什么)。我的问题是,除了偏好之外,这样做还有什么特别的原因吗?如中所述,如果不重置自动增量并保持原样,是否会对数据库或将来的查询产生不利影响?如果有的话,有人能举个例子说明有必要重置自动增量吗?谢谢!
0ve6wy6x1#
我不认为有必要重置自动增量,除非你的值用完了。自动增量经常被重置的一种情况是删除所有行。如果你使用 truncate table ,则自动重置自动增量值。这种情况并不总是发生在 delete 没有一个 where 子句,因此为了保持一致性,您可能需要重置它。另一种情况是大型插入失败,尤其是重复失败时。你可能不想要真正大的差距。在移动表时,您可能希望保留原始的id值。因此,本质上,忽略插入的自动增量。不过,之后您可能希望将自动值设置为与其他系统一致。不过,通常不建议重置自动增量。
truncate table
delete
where
b1uwtaje2#
不幸的是,我见过这种行为。从我观察到的情况来看,这并不是因为技术原因——它更接近强迫症。有些人真的不喜欢id列中的间隔-他们喜欢这样的想法:每一个记录的间隔平滑地增加1。他们所做的一些手工数据操作把数据搞砸了,这种想法并不令人愉快——因此他们要经历一些困难,以确保不会造成数字上的差距。但是,是的,这是一个可怕的做法。它只是要求数据完整性问题。
pgvzfuti3#
重置auto inc是一个不常见的操作。在正常的日常工作中,让它不断增加。我已经在用于自动测试的mysql示例中重置了auto inc。给定的一组表反复加载数据,然后删除其测试数据。如果测试在结果中寻找特定的值,重置auto inc可能是使测试可重复的最佳方法。另一种情况是创建存档表时。假设您有一个巨大的表,并且希望高效地清空数据(不使用delete),但是您希望归档数据,并且希望新数据使用比旧数据更高的id值。
CREATE TABLE mytable_new LIKE mytable; SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME='mytable'; ALTER TABLE mytable_new AUTO_INCREMENT = /* value + 10000 */; RENAME TABLE mytable TO mytable_archive, mytable_new TO mytable;
上面的一系列语句允许您将一个新的空表以原子方式洗牌到适当的位置,这样您的应用程序就可以继续按它使用的名称向表中写入数据。在新表中重置的auto inc值应该高于旧表中的max id值,加上一些适当的间隙,以避免语句之间的重叠。
11dmarpk4#
根据对abr答案的评论,假设自动增量id是连续的(甚至是连续的)不仅是个坏主意,而且是个危险的主意。如果您打算在以后修补数据(例如,如果您已从旧备份还原,并希望恢复一些丢失的数据,但需要尽快恢复服务),或者从单个活动服务器迁移到多个主节点,则有充分的理由故意在分配的ID中创建间隙。但在这些场景中,您将计数器设置为比当前使用的值更高的值—而不是将其重置回开始位置。如果有一种风险,那就是您可能要将数字 Package 起来,那么您可能为自动增量属性选择了错误的数据类型—更改数据类型是解决问题的正确方法,而不是删除数据并将计数器重置为0。
ttygqcqt5#
重置自动增量通常有助于组织,如果删除了id 6和60之间的行,则可以看到id 6和60之间没有间隙。但是,您应该小心地重新设置自动增量,因为您的代码很可能依赖于特定的id来获取某些信息。在我看来,只需在测试之后截短整个内容,并在数据库中植入正确的信息。如果是生产,任由它肆无忌惮地乱跑,可能会造成更大的危害,没有效益的产出
5条答案
按热度按时间0ve6wy6x1#
我不认为有必要重置自动增量,除非你的值用完了。
自动增量经常被重置的一种情况是删除所有行。如果你使用
truncate table
,则自动重置自动增量值。这种情况并不总是发生在delete
没有一个where
子句,因此为了保持一致性,您可能需要重置它。另一种情况是大型插入失败,尤其是重复失败时。你可能不想要真正大的差距。
在移动表时,您可能希望保留原始的id值。因此,本质上,忽略插入的自动增量。不过,之后您可能希望将自动值设置为与其他系统一致。
不过,通常不建议重置自动增量。
b1uwtaje2#
不幸的是,我见过这种行为。从我观察到的情况来看,这并不是因为技术原因——它更接近强迫症。
有些人真的不喜欢id列中的间隔-他们喜欢这样的想法:每一个记录的间隔平滑地增加1。他们所做的一些手工数据操作把数据搞砸了,这种想法并不令人愉快——因此他们要经历一些困难,以确保不会造成数字上的差距。
但是,是的,这是一个可怕的做法。它只是要求数据完整性问题。
pgvzfuti3#
重置auto inc是一个不常见的操作。在正常的日常工作中,让它不断增加。
我已经在用于自动测试的mysql示例中重置了auto inc。给定的一组表反复加载数据,然后删除其测试数据。如果测试在结果中寻找特定的值,重置auto inc可能是使测试可重复的最佳方法。
另一种情况是创建存档表时。假设您有一个巨大的表,并且希望高效地清空数据(不使用delete),但是您希望归档数据,并且希望新数据使用比旧数据更高的id值。
上面的一系列语句允许您将一个新的空表以原子方式洗牌到适当的位置,这样您的应用程序就可以继续按它使用的名称向表中写入数据。在新表中重置的auto inc值应该高于旧表中的max id值,加上一些适当的间隙,以避免语句之间的重叠。
11dmarpk4#
根据对abr答案的评论,假设自动增量id是连续的(甚至是连续的)不仅是个坏主意,而且是个危险的主意。
如果您打算在以后修补数据(例如,如果您已从旧备份还原,并希望恢复一些丢失的数据,但需要尽快恢复服务),或者从单个活动服务器迁移到多个主节点,则有充分的理由故意在分配的ID中创建间隙。但在这些场景中,您将计数器设置为比当前使用的值更高的值—而不是将其重置回开始位置。
如果有一种风险,那就是您可能要将数字 Package 起来,那么您可能为自动增量属性选择了错误的数据类型—更改数据类型是解决问题的正确方法,而不是删除数据并将计数器重置为0。
ttygqcqt5#
重置自动增量通常有助于组织,如果删除了id 6和60之间的行,则可以看到id 6和60之间没有间隙。
但是,您应该小心地重新设置自动增量,因为您的代码很可能依赖于特定的id来获取某些信息。
在我看来,只需在测试之后截短整个内容,并在数据库中植入正确的信息。如果是生产,任由它肆无忌惮地乱跑,可能会造成更大的危害,没有效益的产出