1. 面試官:MySQL自增主鍵為什么不是連續(xù)的?

        共 2957字,需瀏覽 6分鐘

         ·

        2022-12-22 00:03

        ed605c340ae97c96b8c2f8f25b7b9a6e.webp程序員的成長之路互聯網/程序員/技術/資料共享? 關注


        閱讀本文大概需要 3?分鐘。

        來自:blog.csdn.net/jack1liu/article/details/99699201

        一 前言

        提出這個問題,是因為在工作中發(fā)現 mysql 中的 user 表的 id 默認是自增的,但是數據庫存儲的結果卻不是連續(xù)的。user 表結構:
            

        CREATE?TABLE?`user`?(?
        ?`id`?bigint(20)?unsigned?NOT?NULL?AUTO_INCREMENT?COMMENT?'遞增id',?
        ?`name`?varchar(20),
        ?`create_time`?datetime?DEFAULT?CURRENT_TIMESTAMP?COMMENT?'創(chuàng)建時間',?
        ?`update_time`?datetime?DEFAULT?CURRENT_TIMESTAMP?COMMENT?'更新時間',?
        ?PRIMARY?KEY?(`id`),UNIQUE?KEY?`idx_name`?(`name`))?
        ENGINE=InnoDB?AUTO_INCREMENT=1?DEFAULT?CHARSET=utf8mb4?COMMENT='user表'

        user 表存儲:5dc0ee4c81818a69617e6b9132185790.webp

        二 自增值存儲說明

        1.1.MyISAM 引擎的自增值保存在數據文件中。1.2.InnoDB 引擎的自增值,其實是保存在了內存里,并且到了 MySQL 8.0 版本后,才有了“自增值持久化”的能力,也就是才實現了“如果發(fā)生重啟,表的自增值可以恢復為 MySQL 重啟前的值”,具體情況是:
        • 在 MySQL 5.7 及之前的版本,自增值保存在內存里。每次重啟后,第一次打開表的時候,都會去找自增值的最大值?max(id),然后將?max(id) + 1?作為這個表當前的自增值。

        • 在 MySQL 8.0 版本,將自增值的變更記錄在了?redo log?中,重啟的時候依靠?redo log恢復重啟之前的值。

        三 自增值修改機制

        在 MySQL 里面,如果字段 id 被定義為?AUTO_INCREMENT,在插入一行數據的時候,自增值的行為如下:
        • 如果插入數據時 id 字段指定為 0、null 或未指定值,那么就把這個表當前的?AUTO_INCREMENT值填到自增字段;

        • 如果插入數據時 id 字段指定了具體的值,就直接使用語句里指定的值。

        根據要插入的值和當前自增值的大小關系,自增值的變更結果也會有所不同。假設,某次要插入的值是 X,當前的自增值是 Y。
        • 如果 X<Y,那么這個表的自增值不變;

        • 如果 X≥Y,就需要把當前自增值修改為新的自增值。

        新的自增值生成算法是:從?auto_increment_offset?開始,以?auto_increment_increment為步長,持續(xù)疊加,直到找到第一個大于 X 的值,作為新的自增值。其中,auto_increment_offset??auto_increment_increment?是兩個系統參數,分別用來表示自增的初始值和步長,默認值都是 1。

        四 自增值修改時機

            

        insert?into?user?values(null,?'張三');?

        1. 當執(zhí)行上述 SQL 時,執(zhí)行器調用 InnoDB 引擎接口寫入一行,傳入的這一行的值是?(0,"張三")
        2. InnoDB 發(fā)現 SQL 沒有指定自增 id 的值,獲取 user 表當前的自增值 2;
        3. 將傳入的行的值改成?(2,"張三");
        4. 將表的自增值改成 3;
        5. 繼續(xù)執(zhí)行插入數據操作。

        五 導致自增值不連續(xù)的原因

        5.1 唯一鍵沖突

        假設執(zhí)行 SQL 的時候 user 表?id = 10,此時在內存中的自增 id 為11,此時發(fā)生唯一鍵沖突寫庫失敗,則 user 表沒有?id = 10?這條記錄,之后 id 從11開始寫入,因此 id 是不連續(xù)的。

        5.2 事務回滾

        假設同時需要對 user、staff 表進行寫庫操作,執(zhí)行 SQL 的時候 user 表?id = 10,此時在內存中的自增 id 為11;staff 表?id = 20,此時內存中的自增 id 為21,一旦事務執(zhí)行失敗,事務回滾,寫庫失敗,則 user 表沒有?id = 10?這條記錄,staff 表沒有?id = 20?這條記錄,user 表從11開始寫入,staff 表從21開始寫入,如此產生 id 不連續(xù)的現象。

        5.3 批量寫庫操作

        對于批量插入數據的語句,MySQL 有一個批量申請自增 id 的策略:
        1. 語句執(zhí)行過程中,第一次申請自增 id,會分配 1 個;
        2. 1 個用完以后,這個語句第二次申請自增 id,會分配 2 個;
        3. 2 個用完以后,還是這個語句,第三次申請自增 id,會分配 4 個;
        依此類推,同一個語句去申請自增 id,每次申請到的自增 id 個數都是上一次的兩倍。假設批量往 user 表中寫入四條記錄,則這四條記錄將分為三次申請id,第一次分配到?id = 1,第二次分配到?id = 2、3?,第三次分配到?id = 4、5、6、7,當批量寫入四條記錄之后,id = 1、2、3、4將會入庫,但是?id = 5、6、7就被廢棄了,下一個 id 從8開始。

        六 參考文檔

        • https://time.geekbang.org/column/intro/139
        <END>

        推薦閱讀:

        Java使用 try catch會影響性能?
        Java 自帶的性能調優(yōu)神器!!
            
                互聯網初中高級大廠面試題(9個G)
              
            

        內容包含Java基礎、JavaWeb、MySQL性能優(yōu)化、JVM、鎖、百萬并發(fā)、消息隊列、高性能緩存、反射、Spring全家桶原理、微服務、Zookeeper......等技術棧!

        ?戳閱讀原文領取! ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??朕已閱? 0b70192358e4752a6a5a26c559404c9a.webp

        瀏覽 41
        點贊
        評論
        收藏
        分享

        手機掃一掃分享

        分享
        舉報
        評論
        圖片
        表情
        推薦
        點贊
        評論
        收藏
        分享

        手機掃一掃分享

        分享
        舉報
          
          

            1. 做爱网站那个能看 | 舌头伸进去舔我的好爽高潮 | 全黄裸体做爰视频 | 久久国产精品一区 | 黄色小说排行榜 |