大家好，我是雷哥。

如果你用過(guò)或者了解過(guò)MySQL，那么你一定知道自增字段。 每個(gè)自增id都定義了初始值，然后按照指定的步長(zhǎng)遞減（默認(rèn)步長(zhǎng)為1）。 其實(shí)自然數(shù)是沒(méi)有上限的，而我們?cè)谠O(shè)計(jì)表結(jié)構(gòu)的時(shí)候，通常會(huì)指定主鍵的寬度，所以這時(shí)候id是有上限的。 既然有上限，那總會(huì)用完的。 id用完了怎么辦？ 明天上去學(xué)習(xí)。

自增id

說(shuō)到自增id，相信大家的第一反應(yīng)一定是在設(shè)計(jì)表結(jié)構(gòu)的時(shí)候自定義一個(gè)自增id數(shù)組，這樣就有問(wèn)題了。 插入數(shù)據(jù)時(shí)，有可能只有一個(gè)字段被flush，回滾SQL事務(wù)。 1、批量插入時(shí)，由于批量申請(qǐng)自增等激勵(lì)，導(dǎo)致自增id不連續(xù)。

注意

文末：3625頁(yè)各大互聯(lián)網(wǎng)公司筆試題

表中定義的自增值上線(xiàn)后的邏輯是：申請(qǐng)下一個(gè)id時(shí)，獲取相同的值（最大值）。 可以插入SQL設(shè)置id為最大值，另外一句不主動(dòng)設(shè)置id可以驗(yàn)證這個(gè)推斷。 這時(shí)候再插入就會(huì)報(bào)字段沖突~

這里提醒一下：232-1()并不是一個(gè)很大的數(shù)字，對(duì)于一個(gè)頻繁插入和刪除數(shù)據(jù)的表來(lái)說(shuō)可能用完了。 所以在建表的時(shí)候需要檢查一下你的表是否有可能達(dá)到這個(gè)上限。 如果可能，應(yīng)使用 8 個(gè)字節(jié)創(chuàng)建它。

系統(tǒng)增量

如果你創(chuàng)建一個(gè)沒(méi)有指定字段的表，這將為你創(chuàng)建一個(gè)不可見(jiàn)的，厚度為 6 個(gè)字節(jié)。 維護(hù)全局值。 對(duì)于所有沒(méi)有字段的表，每次插入一行數(shù)據(jù)，都以當(dāng)前值作為要插入的數(shù)據(jù)，然后是.的值。 增加 1。

其實(shí)代碼實(shí)現(xiàn)的時(shí)候是一個(gè)無(wú)符號(hào)長(zhǎng)整型()，寬度為8字節(jié)。 而且在設(shè)計(jì)的時(shí)候只剩下6個(gè)字節(jié)的寬度，所以數(shù)據(jù)表中只放了最后6個(gè)字節(jié)，所以數(shù)據(jù)表中的值能講出來(lái)有兩個(gè)特點(diǎn)：

表中所寫(xiě)的取值范圍是從0到248-1； 當(dāng).=2^48時(shí)，如果再有插入數(shù)據(jù)申請(qǐng)的動(dòng)作，收到后取最后6個(gè)字節(jié)，則為0。

其實(shí)2^48這個(gè)數(shù)字已經(jīng)很大了，要知道一個(gè)系統(tǒng)可以運(yùn)行很長(zhǎng)時(shí)間，達(dá)到上限還是有可能的。 這個(gè)時(shí)候再次申請(qǐng)會(huì)覆蓋原來(lái)的記錄。 為此，盡量不要選擇這些方法！

Xid

和MySQL合作時(shí)，有一個(gè)共同的數(shù)組，叫做Xid。 用于對(duì)應(yīng)MySQL中的事務(wù)。

MySQL內(nèi)部維護(hù)了一個(gè)全局變量，每執(zhí)行一句語(yǔ)句就參數(shù)化，然后給這個(gè)變量加1。 如果當(dāng)前語(yǔ)句是本次事務(wù)執(zhí)行的第一句，MySQL也會(huì)同時(shí)將形參賦給本次事務(wù)的Xid。 是純顯存變量，重啟后清零。 因此，在同一個(gè)數(shù)據(jù)庫(kù)實(shí)例中intellij idea 重置默認(rèn)視圖，不同事務(wù)的Xid可能是相同的。

內(nèi)部維護(hù)了一個(gè)全局變量，每次需要申請(qǐng)一個(gè)新的，就獲取當(dāng)前值，之后會(huì)加1。

數(shù)據(jù)可見(jiàn)性的核心思想是：每一行數(shù)據(jù)記錄它的更新。 當(dāng)一個(gè)事務(wù)讀取一行數(shù)據(jù)時(shí)，判斷該數(shù)據(jù)是否可見(jiàn)的方法是將該行數(shù)據(jù)與事務(wù)的一致視圖進(jìn)行比較。 比較的。 而且這個(gè)過(guò)程中有臟讀，所以這個(gè)id不會(huì)是原子的，有重復(fù)的可能。

雖然， id是MySQL中最常見(jiàn)的自增id。 通常我們查看各個(gè)站點(diǎn)時(shí)，上面顯示的第一欄是。

邏輯很容易理解：系統(tǒng)保存一個(gè)全局變量，每創(chuàng)建一個(gè)新連接，就把形參賦給新連接的線(xiàn)程變量。

定義的大小是4個(gè)字節(jié)，所以到達(dá)232-1后，會(huì)被重置為0，然后繼續(xù)遞減。 結(jié)果與原始記錄相同intellij idea 重置默認(rèn)視圖，將被覆蓋。

它引入了MySQL自身的一些自增id。 雖然，在實(shí)踐中，我們也可能會(huì)選擇外部的自增字段，然后持久化到數(shù)據(jù)庫(kù)中，來(lái)代替數(shù)據(jù)庫(kù)本身的自增id。 接下來(lái)聊聊吧。

Redis自增字段

雖然生成外部自增字段的方式有很多種，但為什么要引入redis呢？ 因?yàn)槲以趯?shí)際應(yīng)用中發(fā)現(xiàn)了它的很多優(yōu)點(diǎn)。

Redis本身是原子的，所以高并發(fā)也是線(xiàn)程安全的。 假設(shè)字段數(shù)組的厚度為20，我們使用時(shí)間+自增組成字段，例如：8位日期+12自增。 這樣，根據(jù)業(yè)務(wù)的性質(zhì)，時(shí)間可以確定為取年、月、日或微秒級(jí)別。 這樣微秒之間的自增數(shù)重復(fù)概率極小，可以應(yīng)用基礎(chǔ)業(yè)務(wù)。

總結(jié)

它引入了幾個(gè)自增id，每個(gè)id都有自己的應(yīng)用場(chǎng)景，達(dá)到上限后表現(xiàn)不同：

1.表的自增id達(dá)到上限后，重新申請(qǐng)時(shí)其值不會(huì)改變，導(dǎo)致繼續(xù)往晨報(bào)字段沖突中插入數(shù)據(jù)的錯(cuò)誤

2、達(dá)到上限后，會(huì)回到0，然后再次增加。 如果同樣發(fā)生，后面寫(xiě)入的數(shù)據(jù)會(huì)覆蓋前面的數(shù)據(jù)

3.xid只需要在同一個(gè)文件中不存在重復(fù)值即可。即使理論上存在重復(fù)值，而且概率極小，也可以忽略

4. 的增量值。 每次重啟MySQL都會(huì)保存，所以我們文章中提到的臟讀反例是必然出現(xiàn)的bug。 幸好我們還有大把的時(shí)間

5.是我們使用中最常見(jiàn)的，也是最好的自增id邏輯

6、redis外部自增，微秒級(jí)別，理論上會(huì)有重復(fù)值，概率極小，可以忽略

7、其實(shí)每個(gè)自增id都有自己適用的場(chǎng)景，大家可以在日常使用中根據(jù)具體場(chǎng)景來(lái)選擇。 并且未雨綢繆，因?yàn)橐紤]到系統(tǒng)的運(yùn)行時(shí)間和數(shù)據(jù)的存儲(chǔ)，綜合考慮，在系統(tǒng)運(yùn)行過(guò)程中選擇的瞬間不會(huì)重復(fù)出現(xiàn)。 你學(xué)會(huì)了嗎？

近期技術(shù)文章

過(guò)去的推薦

第三版：互聯(lián)網(wǎng)大咖筆試題

包括Java集合、JVM、多線(xiàn)程、并發(fā)編程、設(shè)計(jì)模式、算法調(diào)優(yōu)、全家桶、Java、、、Dubbo、、、Redis、MySQL、Kafka、Linux、Netty、、、HTML、CSS、Vue、React、 、大數(shù)據(jù)、阿里巴巴等大廠筆試題等，還有其他技術(shù)棧！

如有侵權(quán)請(qǐng)聯(lián)系刪除！