如何處理PK溢出？

應該如何處理PK可能溢出的情況？如何處理PK溢出？

這是不可能的，但仍然有可能。我看到一個通訊退出表單不起作用，因爲它可能有很多請求。

在應用程序端可以做些什麼？ MySQL可以做什麼？

2013-03-04 James P.

如果您擔心，您可以使用'bigint'，這是不太可能超過其最大值 – iTech 2013-03-04 05:22:59

是的，這是一個實際的解決方案。這裏的關鍵字不太可能。像地球一樣突然成爲星際聯邦的一部分，並且每年都必須處理來自外太空的數十億人的訪問：p。 – 2013-03-04 05:49:34

在現實生活中，可能發生的情況是數據庫是由外部公司設計的，直到公司突然意識到某件事情出錯爲止。在十年或更長的時間裏，這不太可能。這就是爲什麼我很好奇看到的是，如果有人有另一種方式解決這個問題的經驗。說，通過檢索未使用的PK值，使用另一個表或不同的東西。在理想條件下，實際上可能是在數據庫的整個生命週期中保持一顆眼睛，這是開發團隊和數據庫管理員不時處理的事情。 – 2013-03-04 05:51:41

應該如何處理PK可能溢出的情況？

簡單的解決方案是設計架構，以便PK的類型足夠大，以至於在任何合理的用例中溢出都不會發生。

如果這種假設失敗，那麼你有一個問題。我可以想到一些可能的選擇。

將PK類型更改爲「更大」的類型，修改應用程序並遷移數據。
寫一個應用程序來「緊湊」的關鍵空間;即對於每個活動密鑰，使用新密鑰更新所有使用該密鑰的記錄，從空間的開始開始。
包裝密鑰空間，並使用更復雜的生成器獲取下一個密鑰，該密鑰檢查每個候選密鑰是否已被使用。

注意，這種事情通常不會設計成一個系統，這不僅是因爲它是很難預料和難以測試。

來源

2013-03-04 06:06:28

我曾在一個32位INT溢出的情況下工作。這是因爲該應用程序意外地爲每個成功的行插入跳過了1000個值。在這種情況下，應用程序達到了最高的已簽名INT值，並且他們無法在該表上再插入任何插入內容。我被調用來幫助他們重構表格以使用BIGINT主鍵。

但是當然之前這樣做，我們必須改變引用表的所有外鍵以使用BIGINT。因爲我們不想在主表中插入一個新的PK值，而這個主表不能被其他表中的FK引用。

應該花費比我們的生命更長的時間來耗盡BIGINT中的值範圍 - 除非每次插入新行時都跳過十億個值！

我寫了一個名爲pk-full-ratio的腳本，它將檢查給定數據庫中的每個AUTO_INCREMENT PRIMARY KEY，並計算它溢出的接近程度（百分比）。

來源

2013-03-04 06:28:14

爲您的腳本+1。 – kwelsan 2013-03-04 10:46:05

如何處理PK溢出？

回答

相關問題