[[415292]]

本文轉載自微信公眾號「后端研究所」，作者大白斯基 。轉載本文請聯系后端研究所公眾號。

大家好，我是后端研究所大白所長!

今天和大家聊一個有趣的話題：

假如MySQL建表時主鍵ID是int32且自增的，誰也沒想到業務發展這么快，今天忽然發現ID耗盡了，各種報警要炸鍋了，請求作為后端owner的你該如何處理?

話不多說，看看我的好兄弟小黑是如何處理的，開車!

1方案一：怒刷簡歷 提桶跑路

這個方案很簡單，怎么處理我不管，提桶跑路!

OS-1：試想大家滿懷信心地加入到了一家公司，等待你的卻是屎山一樣的代碼。

OS-2：這個項目的紅利已經被前輩們吃完了，剩下的就是需要人來維護，哦，沒錯，沒有人會在意誰在維護的，因為已經沒人關注嘍。

OS-3：本以為要來指點江山，誰知道卻是不停填坑，唉，搞了半天還是搞土木工程的!

內心波瀾起伏，終于小黑決定關上手機、下班跑路，回家改起了簡歷，決定提桶跑路。

畫外音：小黑這種做法是不可取的，畢竟跳槽很多時候就是從一個坑到另外一個坑，還是要正視問題，努力解決才行嘛，最后我們祝福小黑。

2方案二：救命的空洞

報警還在呼呼發，小黑的臉更黑了，內心慌得一批，旁邊的同事大劉見狀說："小黑別慌，先及時止損，再尋找徹底解決的方案"。

聽聽，聽聽，大劉一出手就是老架構師的味道。

大劉深知光扯方法論有個屁用，拿出解決方案才是硬道理。圖片

大劉說："小黑你看下這個表的ID是從1開始的嗎?在建表初期有沒有空洞之類的，先讓數據強制寫到前面空洞區域，緩解一下線上危機，再找DBA把ID的字段改成bigINT。"

小黑迅速get到大劉的意思，迅速看了一下，還真有100w的空洞啊!

小黑的淚水奪目而出，恨不得抱著大劉說："恩人啊大劉。"

說干就干，小黑花了10分鐘改完走了快速上線，終于報警慢慢降下來了，100w的空洞夠用幾天了，小黑的臉也沒這么黑了。

接著小黑找到了DBA老張，和老張說明了情況于是開始了在線修改字段類型，由于表很大，這個操作非常耗時，好在空洞可以撐一段時間。

終于在晚上6點表字段改成了bigint，從32位到64位再也不用擔心會耗盡了。

小黑拉上大劉和老張來到了肉串汪，好好謝謝這兩位大神。

畫外音：快謝謝身邊那些每次都提出切實可行方案的同事吧，要成為老架構師的路還長著呢，小黑加油!

3方案三：忍痛割愛

報警就像龍卷風一樣吹得小黑頭暈目眩，小黑想到了圖靈、想到了馮諾依曼、想到了馬云、想到了馬化騰...

一番思想斗爭之后，小黑決定迎難而上，干!

旁邊大劉湊過來說："小黑別慌，這個是已知問題，可能是之前的人沒交接清楚，挖了這個坑"。

小黑看著大劉說："大劉有啥好辦法嗎?"

大劉道："大原則是優先止損，則深度解決，印象中ID是從1開始的沒有空洞，但是早期的數據應該不用了，你可以回收一波，騰出空間讓新數據寫到舊ID上，業務影響有限可以及時止損。"

小黑get了大劉的意思，好在前幾天剛寫了個刪庫腳本，沒想到派上用場了，小黑改了一點拿到線上環境回收了100w個ID，但是這100w個ID并不是連續的。

小黑想了一下，決定加個中間層，把這100w個ID先存儲到了redis中，線上服務先讀redis拿到可用的ID再進行寫庫，從而緩解了問題。

快速修復上線后，報警逐漸降下來了，于是小黑抓緊找到了DBA老張來修改ID字段類型。

終于在晚上6點表字段改成了bigint，從32位到64位再也不用擔心會耗盡了。

小黑拉上大劉和老張來到了木屋燒烤，好好謝謝這兩位大神。

畫外音：問題總會有解決方案的，平時注意積累，關鍵時刻可以提供解決問題的速度，平時多流汗，戰時少流淚。

4小結

對于這個問題，網上很多相關的文章，基本上都是再說改成bigint，這種說法不能說錯，但是不夠及時雨。

試想32位都寫滿了的大表，改字段要消耗多久?這期間的新寫數據怎么辦?并不能及時止損，P0事故是跑不了了。

除了文中的幾種方案，結合具體的場景還會有其他做法：比如新建一張表，雙讀&單寫新表，總之方法不止一種，結合場景&及時止損才是真正的好方案。

就寫這么多吧!