DBeaver 的自動增量欄位最大值為 2147483647 - 為什麼？
在 DBeaver 中，當右鍵點擊“外鍵”選擇“查看外鍵”時，會顯示以下資訊頁面：
我認為“自動增量”欄位值將讀取 1（或其他一些小數字）以指示該外鍵自動遞增的步長值。
相反，我看到 MAX INT 32 位 (2147483647) 的值。
這個值是什麼意思？
2 的 32 次方是 4294967296。
如果你把它除以 2，你會得到：
(2^32/2) = 2147483648
第二個值減 1
2147483647= 2^31 - 1，即您的興趣值。在數學上，它是第 8 個梅森素數，也等於十六進制（以 16 為底）值
7FFF,FFFF。它也是double Mersenne prime該類數字中已知的最大和（可能）最大的！在數據庫和計算中，它是 32 位的最大大小
SIGNED INTEGER。有符號/無符號整數類型是 MySQL 優於 PostgreSQL 的少數領域之一。我認為 unsigned INTEGERs 有很多潛在的用途，但話說回來，PostgreSQL 有CHECK CONSTARAINTs 這意味著強制將正整數作為一種類型並不是強制性的。儘管如此（個人意見），我覺得這是一個很好的類型，如果只是為了簡潔和清晰！以前（在許多 32 位系統中），它是
2147483647表中允許的最大記錄數（即 ）和/或AUTO_INCREMENTing（即 SERIAL 或 SEQUENCE）整數欄位可以達到的最大值 - 但現在通常不是這種情況用 64 位機器。當達到這個數字時，無論是記錄數還是某種鍵，那麼許多數據庫系統的行為要麼沒有記錄，要麼不穩定，或者兩者兼而有之。該值可以從零重新開始（可能違反完整性約束）或從任意值開始或導致系統完全崩潰！
在 2038 年 1 月 19 日（UTC 時間 03:14:07），
2147483647自 1970 年 1 月 1 日以來經過的 ( ) 秒beginning of time將超過Unix is concerned. 飛機會從天上掉下來，核導彈會毫無挑釁地發射，通常會發出巨大的哀號和咬牙切齒的聲音——當然，除非你是一個能從中大賺一筆的程序員（就像！2000）。2038 年問題涉及將許多數字系統中的時間表示為自 1970 年 1 月 1 日以來經過的秒數，並將其儲存為帶符號的 32 位二進制整數。此類實現無法對 2038 年 1 月 19 日 03:14:07 UTC 之後的時間進行編碼。就像 Y2K 問題一樣，2038 年問題是由所選儲存單元的容量不足引起的。
現在最好完全避免使用 64 位！