自動增量列用完時會發生什麼情況？

考慮與自動增量列這樣一個簡單的表：自動增量列用完時會發生什麼情況？

CREATE TABLE foo 
(
    `fooid` bigint unsigned NOT NULL auto_increment, 
    ....snipped.... other columns 
    PRIMARY KEY (`fooid`) 
) 
ENGINE=InnoDB AUTO_INCREMENT=10

一個人如何重新設計這讓我們不打Bigint數據類型的最大？無符號範圍是0到18446744073709551615. 我不知道需要多長時間才能達到18446744073709551615，但是像Y2K問題一樣，我想爲它做好準備。

來源

2008-12-12 ashitaka

假設您每毫秒插入一行。

18446744073709551615個millseconds = 18446744073709552秒= 307445734561826分鐘= 5124095576030小時= 213503982335天= 584942417年

所以它不是真的像千年蟲問題

你可以插入一個萬元每毫秒行數爲，超過500年仍然可以。

換句話說：不要擔心。

來源

2008-12-12 07:34:01

好的。我不認爲我的應用會持續這麼長的時間=> 500年。 – ashitaka 2008-12-12 07:40:46

同樣，如果您只需每秒插入一次，則您的應用程序將運行68年，並使用32位帶符號整數。如果可以，請保存4個字節的記錄並使用32位整數。 – jmucchiello 2008-12-12 07:51:01

根據您使用的是哪個SQL mode，當AUTO_INCREMENT數字列的值超出範圍時，MySQL會執行以下兩項操作之一。無論是哪種情況，都會出現錯誤，但出於不同的原因。

嚴格模式 MySQL拒絕超出範圍值，拋出無效值錯誤，並且INSERT失敗。在默認非嚴格模式下 MySQL將該值降低到數據類型允許的最高值，並執行INSERT。但INSERT失敗，因爲AUTO_INCREMENT屬性已經引起所有已被使用的可能值，你會得到這個錯誤（無符號SMALLINT爲例）：

MySQL said: 

#1062 - Duplicate entry '65535' for key 1

對於BIGINT例如這裏，取代了「65535」與儘管在生產數據庫中這種錯誤不太可能發生。

但隨着TINYINT S和SMALLINT■如果你低估了在應用程序的生命週期可能的鍵值（的INSERT的號碼），它可以非常容易地發生。想象一下，您正在更改您的代碼並測試您的數據是否正確插入。突然你的應用程序退出處理上面的錯誤。您將更改回滾到已知的良好代碼，但錯誤不會消失......非常令人沮喪。

來源

2008-12-12 11:02:44 flamingLogos

不知道MySQL，但在Postgresql的情況下，您可以指定序列是否爲CYCLE/NO CYCLE。如果使用CYCLE選項創建，它將會再次回到1（或minvalue），並會爲重複鍵引發錯誤。

來源

2008-12-12 11:08:02 cnu

自動增量列用完時會發生什麼情況？

回答

相關問題