MYSQL的自增列在實際生產(chǎn)中應(yīng)用的非常廣泛,相信各位所在的公司or團(tuán)隊,MYSQL開發(fā)規(guī)范中一定會有要求盡量使用自增列去充當(dāng)表的主鍵,為什么DBA會有這樣的要求,各位在使用MYSQL自增列時遇到過哪些問題?這些問題是由什么原因造成的呢?本文由淺入深,帶領(lǐng)大家徹底弄懂MYSQL的自增機(jī)制。
創(chuàng)新互聯(lián)建站是創(chuàng)新、創(chuàng)意、研發(fā)型一體的綜合型網(wǎng)站建設(shè)公司,自成立以來公司不斷探索創(chuàng)新,始終堅持為客戶提供滿意周到的服務(wù),在本地打下了良好的口碑,在過去的10多年時間我們累計服務(wù)了上千家以及全國政企客戶,如廣告推廣等企業(yè)單位,完善的項目管理流程,嚴(yán)格把控項目進(jìn)度與質(zhì)量監(jiān)控加上過硬的技術(shù)實力獲得客戶的一致夸獎。
1.? 通過auto_increment關(guān)鍵字來指定自增的列,并指定自增列的初始值為1。
[root@localhost][test1]Create table t(id int auto_increment ,namevarchar(10),primary key(id))auto_increment=1;
QueryOK, 0 rows affected (0.63 sec)
2.? 自增列上必須有索引,將t表的主鍵索引刪除掉,會報錯
[root@localhost][test1]alter table t drop primary key;
ERROR1075 (42000): Incorrect table definition; there can be only one auto column andit must be defined as a key
3.? 設(shè)定auto_increment_increment參數(shù),可以調(diào)整自增步長,該參數(shù)有session級跟global級,在分庫分表以及雙主or多主的模式下比較有用。
4.? 一個表上只能有一個自增列
5.? Mysql5.7及以下版本,innodb表的自增值保存在內(nèi)存中,重啟后表的自增值會設(shè)為max(id)+1,而myisam引擎的自增值是保存在文件中,重啟不會丟失。Mysql8.0開始,innodb的自增id能持久化了,重啟mysql,自增ID不會丟。
首先:表中自增列的上限是根據(jù)自增列的字段類型來定的。
若設(shè)定了自增id充當(dāng)主鍵,當(dāng)達(dá)到了自增id的上限值時,會發(fā)生什么樣的事情呢?還是以上面創(chuàng)建的 t表為例, 先回顧它的表結(jié)構(gòu):
CREATETABLE `t` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(10) COLLATE utf8mb4_binDEFAULT NULL,
PRIMARY KEY (`id`)
)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin
無符號的int類型,上限是2147483647。這里我們將表的自增值設(shè)為2147483647,再插入兩行數(shù)據(jù):
[root@localhost][test1]alter table t auto_increment=2147483647;
QueryOK, 0 rows affected (0.01 sec)
Records:0? Duplicates: 0? Warnings: 0
[root@localhost][test1]insert into t(name) values ('test');??????????
QueryOK, 1 row affected (0.01 sec)
[root@localhost][test1]insert into t(name) values ('test');
ERROR 1062 (23000): Duplicate entry '2147483647' for key 'PRIMARY'
可以看到,第一個插入沒問題,因為自增列的值為2147483647,這是達(dá)到了上限,還沒有超過,第二行數(shù)據(jù)插入時,則報出主鍵重復(fù),在達(dá)到上限后,無法再分配新的更大的自增值,也沒有從1開始從頭分配,在這里表的auto_increment值會一直是2147483647。
對于寫入量大,且經(jīng)常刪除數(shù)據(jù)的表,自增id設(shè)為int類型還是偏小的,所以我們?yōu)榱吮苊獬霈F(xiàn)自增id漲滿的情況,這邊統(tǒng)一建議自增id的類型設(shè)為unsigned bingint,這樣基本可以保障表的自增id是永遠(yuǎn)夠用的。
這里內(nèi)容比較多,innodb是索引組織表,所以涉及到索引的知識,但這不是本文的重點,我們快速回顧索引知識:
1.? Innodb索引分為主鍵跟輔助索引,主鍵即全表,輔助索引葉子節(jié)點保存主鍵的值,而主鍵的葉子節(jié)點保存數(shù)據(jù)行,中間節(jié)點存著葉子節(jié)點的路由值。
2.? Innodb存儲數(shù)據(jù)(索引)的單位是頁,這里默認(rèn)是16K,這也意味著,數(shù)據(jù)本身越小,一個頁中能存數(shù)據(jù)的量越多,而檢索效率不僅僅由索引的層數(shù)來決定,更是由一次能夠緩存的數(shù)據(jù)量來定,也就是說數(shù)據(jù)本身越小,則一次IO能夠提取到緩沖區(qū)的數(shù)據(jù)越多(OS每次IO的量是固定的4K),查詢的效率越好。
其實能夠理解索引的結(jié)構(gòu)及索引寫入插入、更新的原理,則自然就明白為何建議使用自增id。這里我直接列出使用自增id 當(dāng)主鍵的好處吧:
1.? 順序?qū)懭耄苊饬巳~的分裂,數(shù)據(jù)寫入效率好
2.? 縮小了表的體積,特別是相比于UUID當(dāng)主鍵,甚至組合字段當(dāng)主鍵時,效果更明顯
3.? 查詢效率好,原因就是我上面說到索引知識的第二點。
4.? 某些情況下,我們可以利用自增id來統(tǒng)計大表的大致行數(shù)。
5.? 在數(shù)據(jù)歸檔or垃圾數(shù)據(jù)清理時,也可方便的利用這個id去操作,效率高。
容易出現(xiàn)不連續(xù)的id
有的同志會發(fā)現(xiàn),自己的表中id值存在空洞,如類似于1、2、3、8、9、10這樣,有的適合有想依賴于自增id的連續(xù)性來實現(xiàn)業(yè)務(wù)邏輯,所以會想方設(shè)法去修改id讓其變的連續(xù),其實,這是沒有必要的,這一塊的業(yè)務(wù)邏輯交由MySQL實現(xiàn)是很不理智的,表的記錄小還好,要是表的數(shù)據(jù)量很大,修改起來就糟糕了。那么,為什么自增id會容易出現(xiàn)空洞呢?
自增id的修改機(jī)制如下:
在MySQL里面,如果字段id被定義為AUTO_INCREMENT,在插入一行數(shù)據(jù)的時候,自增值的行為如下:
1. 如果插入數(shù)據(jù)時id字段指定為0、null 或未指定值,那么就把這個表當(dāng)前的
AUTO_INCREMENT值填到自增字段;
2. 如果插入數(shù)據(jù)時id字段指定了具體的值,就直接使用語句里指定的值。
根據(jù)要插入的值和當(dāng)前自增值的大小關(guān)系,自增值的變更結(jié)果也會有所不同。假設(shè),某次要插入的值是X,當(dāng)前的自增值是Y。
1. 如果XY,那么這個表的自增值不變;
2. 如果X≥Y,就需要把當(dāng)前自增值修改為 新的自增值 。
新的自增值生成算法是:從auto_increment_offset開始,以auto_increment_increment為步長,持續(xù)疊加,直到找到第一個大于X的值,作為新的自增值。
Insert、update、delete操作會讓id不連續(xù)。
Delete、update:刪除中間數(shù)據(jù),會造成空動,而修改自增id值,也會造成空洞(這個很少)。
Insert:插入報錯(唯一鍵沖突與事務(wù)回滾),會造成空洞,因為這時候自增id已經(jīng)分配出去了,新的自增值已經(jīng)生成,如下面例子:
[root@localhost][test1] select * fromt;
+----+------+
| id | name |
+----+------+
|? 1| aaa? |
|? 2| aaa? |
|? 3| aaa? |
|? 4| aaa? |
+----+------+
4 rows in set (0.00 sec)
[root@localhost][test1] selectAuto_increment from information_schema.tables where table_name='t';
+----------------+
| Auto_increment |
+----------------+
|????????????? 5 |
+----------------+
1 row in set (0.00 sec)
[root@localhost][test1] begin;
Query OK, 0 rows affected (0.00 sec)
[root@localhost][test1] insert intot(name) values('aaa');
Query OK, 1 row affected (0.00 sec)
[root@localhost][test1] select * fromt;
+----+------+
| id | name |
+----+------+
|? 1| aaa? |
|? 2| aaa? |
|? 3| aaa? |
|? 4| aaa? |
|? 5| aaa? |
+----+------+
5 rows in set (0.00 sec)
[root@localhost][test1] selectAuto_increment from information_schema.tables where table_name='t';
+----------------+
| Auto_increment |
+----------------+
|????????????? 6 |
+----------------+
1 row in set (0.00 sec)
[root@localhost][test1] rollback;
Query OK, 0 rows affected (0.00 sec)
[root@localhost][test1] selectAuto_increment from information_schema.tables where table_name='t';
+----------------+
| Auto_increment |
+----------------+
|????????????? 6 |
+----------------+
1 row in set (0.01 sec)
[root@localhost][test1] select * fromt;
+----+------+
| id | name |
+----+------+
|? 1| aaa? |
|? 2| aaa? |
|? 3| aaa? |
|? 4| aaa? |
+----+------+
4 rows in set (0.00 sec)
可以看到,雖然事務(wù)回滾了,但自增id已經(jīng)回不到從前啦,唯一鍵沖突也是這樣的,這里就不做測試了。
在批量插入時(insert select等),也存在空洞的問題。看下面實驗:
[root@localhost][test1] select * fromt;
+----+------+
| id | name |
+----+------+
|? 1| aaa? |
|? 2| aaa? |
|? 3| aaa? |
|? 4| aaa? |
+----+------+
4 rows in set (0.00 sec)
[root@localhost][test1] selectAuto_increment from information_schema.tables where table_name='t';
+----------------+
| Auto_increment |
+----------------+
|????????????? 5 |
+----------------+
1 row in set (0.00 sec)
[root@localhost][test1] insert intot(name) select name from t;??????????????????????
Query OK, 4 rows affected (0.04 sec)
Records: 4?Duplicates: 0? Warnings: 0
[root@localhost][test1] select * fromt;
+----+------+
| id | name |
+----+------+
|? 1| aaa? |
|? 2| aaa? |
|? 3| aaa? |
|? 4| aaa? |
|? 5| aaa? |
|? 6| aaa? |
|? 7| aaa? |
|? 8| aaa? |
+----+------+
8 rows in set (0.00 sec)
[root@localhost][test1] selectAuto_increment from information_schema.tables where table_name='t';
+----------------+
| Auto_increment |
+----------------+
|???????????? 12 |
+----------------+
1 row in set (0.00 sec)
可以看到,批量插入,導(dǎo)致下一個id值不為9了,再插入數(shù)據(jù),即產(chǎn)生了空洞,這里是由mysql申請自增值的機(jī)制所造成的,MySQL在批量插入時,若一個值申請一個id,效率太慢,影響了批量插入的速度,故mysql采用下面的策略批量申請id。
1.? 語句執(zhí)行過程中,第一次申請自增id,會分配1個;
2.? 1個用完以后,這個語句第二次申請自增id,會分配2個;
3.? 2個用完以后,還是這個語句,第三次申請自增id,會分配4個;
4.? 依此類推,同一個語句去申請自增id,每次申請到的自增id個數(shù)都是上一次的兩倍。
在對自增列進(jìn)行操作時,存在著自增鎖,mysql的innodb_autoinc_lock_mode參數(shù)控制著自增鎖的上鎖機(jī)制。該參數(shù)有0、1、2三種模式:
0:語句執(zhí)行結(jié)束后釋放自增鎖,MySQL5.0時采用這種模式,并發(fā)度較低。
1:mysql的默認(rèn)設(shè)置。普通的insert語句申請后立馬釋放,insert select、replace insert、load data等批量插入語句要等語句執(zhí)行結(jié)束后才釋放,并發(fā)讀得到提升
2:所有的語句都是申請后立馬釋放,并發(fā)度大大提升!但是在binlog為statement格式時,主從數(shù)據(jù)會發(fā)生不一致。這一塊網(wǎng)上有很多介紹,我不做介紹了。
在徹底了解了MYSQL的自增機(jī)制以后,在實際生產(chǎn)中就能靈活避坑,這里建議不要用自增id值去當(dāng)表的行數(shù),當(dāng)需要對大表準(zhǔn)確統(tǒng)計行數(shù)時,可以去count(*)從庫,如果業(yè)務(wù)很依賴大表的準(zhǔn)確行數(shù),直接弄個中間表來統(tǒng)計,或者考慮要不要用mysql的innodb來存儲數(shù)據(jù),這個是需要自己去權(quán)衡。另外對于要求很高的寫入性能,但寫入量又比較大的業(yè)務(wù),自增id的使用依然存在熱點寫入的問題,存在性能瓶頸,這時候可通過分庫分表來解決。
兩種方法修改或者重置mysql中的自增字段的值:autoIncrement;
其中方法二可以修改成任意值。
1、創(chuàng)建表時指定AUTO_INCREMENT自增值的初始值(即起始值):
CREATE TABLE XXX (ID INT(5) PRIMARY KEY AUTO_INCREMENT) AUTO_INCREMENT=100;
2、通過 ALTER TABLE 修改初始值(但是要大于表中的 AUTO_INCREMENT 自增值,否則設(shè)置無效):
ALTER TABLE XXX AUTO_INCREMENT=100;
3、如果自增序列的最大值被刪除了,則在插入新記錄時,該值被重用:
就是說如果表中原本有AUTO_INCREMENT屬性值連續(xù)為78、100的值,但100這個數(shù)據(jù)被刪除了,下此再添加數(shù)據(jù)的時候自增值為101,100被重用了。
即使在你將整個表中的所有數(shù)據(jù)delete清空后,之前的自增序列最大值還是會被重用。
解決辦法是:
使用 ALTER TABLE XXX AUTO_INCREMENT=0; 重新設(shè)置自增初始值。
1.主鍵語法
①創(chuàng)建時:create table sc (
studentno int,
courseid int,
score int,
primary key (studentno) );
②修改時:ALTER TABLE table_name ADD CONSTRAINT pk_name PRIMARY KEY(列名);
前提是原先沒有設(shè)置主鍵。
2.外鍵語法
①創(chuàng)建時:create table sc (
studentno int,
courseid int,
score int,
foreign key (courseid) );
②修改時:
ALTER TABLE news_info[子表名] ADD CONSTRAINT FK_news_info_news_type[約束名] FOREIGN KEY (info_id)[子表列] REFERENCES news_type[主表名] (id)[主表列] ;
3.使用組合主鍵
如果一列不能唯一區(qū)分一個表里的記錄時,可以考慮多個列組合起來達(dá)到區(qū)分表記錄的唯一性,形式
①創(chuàng)建時:create table sc (
studentno int,
courseid int,
score int,
primary key (studentno,courseid) );
②修改時:alter table tb_name add primary key (字段1,字段2,字段3);
前提是原來表中沒有設(shè)置主鍵,若原先已有主鍵則會報錯。
文章標(biāo)題:mysql怎么改自增值,mysql修改表自增
鏈接URL:http://www.rwnh.cn/article30/dscddpo.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供外貿(mào)網(wǎng)站建設(shè)、做網(wǎng)站、網(wǎng)站收錄、手機(jī)網(wǎng)站建設(shè)、品牌網(wǎng)站建設(shè)、網(wǎng)站導(dǎo)航
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)