數(shù)據(jù)庫作為功能強大的工具，迄今為止已幫助很多小伙伴完成了繁瑣的工作，但是想要在操作軟件時更省時省力，掌握其中的操作技巧也是不可或缺的一部分。今天，小編就數(shù)據(jù)庫怎么設置id自增，以及數(shù)據(jù)庫自增id用完了...

數(shù)據(jù)庫作為功能強大的工具，迄今為止已幫助很多小伙伴完成了繁瑣的工作，但是想要在操作軟件時更省時省力，掌握其中的操作技巧也是不可或缺的一部分。今天，小編就數(shù)據(jù)庫怎么設置id自增，以及數(shù)據(jù)庫自增id用完了怎么辦為主題，將解決辦法悉數(shù)附上，希望大家喜歡。

數(shù)據(jù)庫怎么設置id自增

1、首先檢查你的新聞表ID列的數(shù)據(jù)類型，要設置為自增列，需要該列的數(shù)據(jù)類型為int或者bigint等數(shù)值類型

2、打開sqlserver management studio,右鍵點擊你的新聞表，選擇“設計”

3、在第1步打開的表結構設置界面，點擊你的列“ID”，在底下的列屬性設置界面做如下設置

4、進行完以上步驟，即可在該數(shù)據(jù)表中插入數(shù)據(jù)時，不用給ID列賦值，ID列的值會自動生成，并且該列的值會自動增長

數(shù)據(jù)庫自增id用完了怎么辦

這個問題其實可以分為有主鍵 & 無主鍵兩種情況回答。

國際慣例，先上張腦圖

有主鍵

如果你的表有主鍵，并且把主鍵設置為自增。

在 MySQL 中，一般會把主鍵設置成 int 型。而 MySQL 中 int 型占用 4 個字節(jié)，作為有符號位的話范圍就是 [-231,231-1]，也就是[-2147483648,2147483647]；無符號位的話最大值就是 2^32-1，也就是 4294967295。

1、下面以有符號位創(chuàng)建一張表

2、插入一個 id 為最大值 2147483647 的值，如下圖所示

3、如果此時繼續(xù)下面的插入語句

4、結果就會造成主鍵沖突

5、解決方案

雖說 int 4 個字節(jié)，最大數(shù)據(jù)量能存儲 21 億。你可能會覺得這么大的容量，應該不至于用完。但是互聯(lián)網(wǎng)時代，每天都產生大量的數(shù)據(jù)，這是很有可能達到的。

所以，我們的解決方案是把主鍵類型改為 bigint，也就是 8 個字節(jié)。這樣能存儲的最大數(shù)據(jù)量就是 2^64-1，我也數(shù)不清有多少了。反正在你有生之年應該是夠用的。

PS：單表 21 億的數(shù)據(jù)量顯然不現(xiàn)實，一般來說數(shù)據(jù)量達到 500 萬就該分表了。

沒主鍵

另一種情況就是建表時沒設置主鍵。這種情況，InnoDB 會自動幫你創(chuàng)建一個不可見的、長度為 6 字節(jié)的 row_id，默認是無符號的，所以最大長度是 2^48-1。

實際上 InnoDB 維護了一個全局的 dictsys.row_id，所以未定義主鍵的表都共享該 row_id，并不是單表獨享。每次插入一條數(shù)據(jù)，都把全局 row_id 當成主鍵 id，然后全局 row_id 加 1。

這種情況的數(shù)據(jù)庫自增 ID 用完會發(fā)生什么呢？

1、創(chuàng)建一張無顯示設置主鍵的表 t：

2、通過 ps -ef|grep mysql 命令獲取 mysql 的進程 ID，然后執(zhí)行命令，通過 gdb 先把 row_id 修改為 1。PS：沒有 gdb 的，百度安裝下

3、出現(xiàn)下圖就是沒錯的

4、插入三條數(shù)據(jù)

5、此時的數(shù)據(jù)庫數(shù)據(jù)

6、gdb 把 row_id 修改為最大值：281474976710656

7、再插入三條數(shù)據(jù)

8、此時的數(shù)據(jù)庫數(shù)據(jù)

分析

剛開始設置 row_id 為 1，插入三條數(shù)據(jù) 1、2、3 的 row_id 也理應是 1、2、3；這是沒問題的。

接著設置 row_id 為最大值，緊跟著插入三條數(shù)據(jù)。這時的數(shù)據(jù)庫結果是：4、5、6、3；你會發(fā)現(xiàn) 1、2 被覆蓋了。

row_id 達到后最大值后插入的值 4、5、6 的 row_id 分別是 0、1、2；由于 row_id 為 1、2 的值已存在，所以后者的值 5、6 會覆蓋掉 row_id 為 1、2 的值。

結論：row_id 達到最大值后會從 0 重新開始算；前面插入的數(shù)據(jù)就會被后插入的數(shù)據(jù)覆蓋，且不會報錯。

總結

數(shù)據(jù)庫自增主鍵用完后分兩種情況：

有主鍵，報主鍵沖突

無主鍵，InnDB 會自動生成一個全局的row_id。它到達最大值后會從 0 開始算，遇到 row_id 一樣時，新數(shù)據(jù)覆蓋舊數(shù)據(jù)。所以，我們還是盡量給表設置主鍵。

數(shù)據(jù)庫自增ID的優(yōu)缺點

優(yōu)點：

1、自增，趨勢自增，可作為聚集索引，提升查詢效率

2、節(jié)省磁盤空間。500W數(shù)據(jù)，UUID占5.4G,自增ID占2.5G.

3、查詢，寫入效率高：查詢略優(yōu)。寫入效率自增ID是UUID的四倍。

缺點：

1、導入舊數(shù)據(jù)時，可能會ID重復，導致導入失敗。

2、分布式架構，多個Mysql實例可能會導致ID重復。

總結：

1、單實例，單節(jié)點，由于InnoDB的特性，自增ID效率大于UUID.

2、20個節(jié)點一下小型分布式架構：為了實現(xiàn)快速部署，主鍵不重復，可以采用UUID

3、20到200個節(jié)點：可以采用自增ID+步長的較快速方案。

4、200個以上節(jié)點的分布式架構：可以采用twitter的雪花算法全局自增ID

以上內容便是數(shù)據(jù)庫怎么設置id自增，以及數(shù)據(jù)庫自增id用完了怎么辦的解決方案，如遇到同類型問題而被困擾已久的朋友們可以試著跟上述提供的解決辦法一步步操作，如果這些解決辦法對大家有所幫助，請多傳閱與關注本站。

本站通過AI自動登載本文內容，文章僅代表原作者個人觀點。本站旨在傳播優(yōu)質文章，文中配圖來源于網(wǎng)絡，無商業(yè)用途。如侵犯您的合法權益請聯(lián)系刪除。