【Java】mysql中的數據庫ID主鍵的設置問題

【前言】

　　一般選擇mysql數據庫中的表中ID主鍵，有以下幾種方式：

• • 　　自增ID
  • 　　雪花（snowflake）算法
  • 　　uuid隨機數
  • 　　redis生成ID

　　本文將會先介紹這幾種算法，然后進行對比，思考什么情況下來選擇ID主鍵的問題。

【算法介紹】

　　一、自增ID

　　　　創建表的時候設置id為自增。 語法為:auto_increment

　　二、uuid隨機數

　　　　需要在程序中進行設置。它的標准型式包含32個16進制數字，以連字號分為五段，表現形式為8-4-4-4-12的32個字符.

import java.util.UUID;

public class UTest {
    public static void main(String[] args) {
        UUID uuid = UUID.randomUUID();
        System.out.println(uuid);
    }
}

　　三、雪花算法

　　　　雪花算法是Twitter開源的分布式ID生成算法。生成的ID是純數字且具有時間順序。

 

　　　

　　　　自增、有序、適合分布式場景，生成時不依賴於數據庫，完全在內存中生成，每秒能生成數百萬的自增 ID，存入數據庫中，索引效率高。　　

• • • 時間位：可以根據時間進行排序，有助於提高查詢速度。
    • 機器 ID 位：適用於分布式環境下對多節點的各個節點進行標識，可以具體根據節點數和部署情況設計划分機器位 10 位長度，如划分5位表示進程位等。
    • 序列號位：是一系列的自增id，可以支持同一節點同一毫秒生成多個 ID 序號，12 位的計數序列號支持每個節點每毫秒產生 4096 個 ID 序號

　　　　snowflake 算法可以根據項目情況以及自身需要進行一定的修改。

　

　　四、Redis生成ID

 

【對比分析】

生成算法	優點	缺點	長度
自增ID	代碼簡單，數據遞增	單點故障，需要DBA專業維護	32
UUID	實現簡單，不占用帶寬	無序、查詢慢、不適合簡歷索引	遞增
雪花算法	低位趨勢遞增，性能高	依賴於服務器時間	18
Redis自增	無單點故障，性能高，遞增	占用帶寬，Redis集群維護	自定義

　　

　　1、代碼時間消耗分析

import cn.hutool.core.collection.CollectionUtil;
import com.wyq.mysqldemo.databaseobject.UserKeyAuto;
import com.wyq.mysqldemo.databaseobject.UserKeyRandom;
import com.wyq.mysqldemo.databaseobject.UserKeyUUID;
import com.wyq.mysqldemo.diffkeytest.AutoKeyTableService;
import com.wyq.mysqldemo.diffkeytest.RandomKeyTableService;
import com.wyq.mysqldemo.diffkeytest.UUIDKeyTableService;
import com.wyq.mysqldemo.util.JdbcTemplateService;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.util.StopWatch;
import java.util.List;

@SpringBootTest
class MysqlDemoApplicationTests {

    @Autowired
    private JdbcTemplateService jdbcTemplateService;

    @Autowired
    private AutoKeyTableService autoKeyTableService;

    @Autowired
    private UUIDKeyTableService uuidKeyTableService;

    @Autowired
    private RandomKeyTableService randomKeyTableService;


    @Test
    void testDBTime() {

        StopWatch stopwatch = new StopWatch("執行sql時間消耗");


        /**
         * auto_increment key任務
         */
        final String insertSql = "INSERT INTO user_key_auto(user_id,user_name,sex,address,city,email,state) VALUES(?,?,?,?,?,?,?)";

        List<UserKeyAuto> insertData = autoKeyTableService.getInsertData();
        stopwatch.start("自動生成key表任務開始");
        long start1 = System.currentTimeMillis();
        if (CollectionUtil.isNotEmpty(insertData)) {
            boolean insertResult = jdbcTemplateService.insert(insertSql, insertData, false);
            System.out.println(insertResult);
        }
        long end1 = System.currentTimeMillis();
        System.out.println("auto key消耗的時間:" + (end1 - start1));

        stopwatch.stop();


        /**
         * uudID的key
         */
        final String insertSql2 = "INSERT INTO user_uuid(id,user_id,user_name,sex,address,city,email,state) VALUES(?,?,?,?,?,?,?,?)";

        List<UserKeyUUID> insertData2 = uuidKeyTableService.getInsertData();
        stopwatch.start("UUID的key表任務開始");
        long begin = System.currentTimeMillis();
        if (CollectionUtil.isNotEmpty(insertData)) {
            boolean insertResult = jdbcTemplateService.insert(insertSql2, insertData2, true);
            System.out.println(insertResult);
        }
        long over = System.currentTimeMillis();
        System.out.println("UUID key消耗的時間:" + (over - begin));

        stopwatch.stop();


        /**
         * 隨機的long值key
         */
        final String insertSql3 = "INSERT INTO user_random_key(id,user_id,user_name,sex,address,city,email,state) VALUES(?,?,?,?,?,?,?,?)";
        List<UserKeyRandom> insertData3 = randomKeyTableService.getInsertData();
        stopwatch.start("隨機的long值key表任務開始");
        Long start = System.currentTimeMillis();
        if (CollectionUtil.isNotEmpty(insertData)) {
            boolean insertResult = jdbcTemplateService.insert(insertSql3, insertData3, true);
            System.out.println(insertResult);
        }
        Long end = System.currentTimeMillis();
        System.out.println("隨機key任務消耗時間:" + (end - start));
        stopwatch.stop();


        String result = stopwatch.prettyPrint();
        System.out.println(result);
    }

 

 

　　時間占用量總體可以打出的效率排名為：auto_key>random_key>uuid。

　　uuid 的效率最低，在數據量較大的情況下，效率直線下滑。那么為什么會出現這樣的現象呢？帶着疑問,我們來探討一下這個問題：

　　使用 uuid 和自增 id 的索引結構對比

　　自增的主鍵的值是順序的，所以 InnoDB 把每一條記錄都存儲在一條記錄的后面。

　　當達到頁面的最大填充因子時候（InnoDB 默認的最大填充因子是頁大小的 15/16，會留出 1/16 的空間留作以后的修改）。①下一條記錄就會寫入新的頁中，一旦數據按照這種順序的方式加載，主鍵頁就會近乎於順序的記錄填滿，提升了頁面的最大填充率，不會有頁的浪費。②新插入的行一定會在原有的最大數據行下一行，MySQL 定位和尋址很快，不會為計算新行的位置而做出額外的消耗。③減少了頁分裂和碎片的產生。

　　使用自增 id 的缺點

　　　　①別人一旦爬取你的數據庫，就可以根據數據庫的自增 id 獲取到你的業務增長信息，很容易分析出你的經營情況。

　　　　②對於高並發的負載，InnoDB 在按主鍵進行插入的時候會造成明顯的鎖爭用，主鍵的上界會成為爭搶的熱點，因為所有的插入都發生在這里，並發插入會導致間隙鎖競爭。

　　　　③Auto_Increment 鎖機制會造成自增鎖的搶奪，有一定的性能損失。

　　　　附：Auto_increment的鎖爭搶問題，如果要改善需要調優 innodb_autoinc_lock_mode 的配置。

 

　　因為 uuid 相對順序的自增 id 來說是毫無規律可言的，新行的值不一定要比之前的主鍵的值要大，所以 innodb 無法做到總是把新行插入到索引的最后，而是需要為新行尋找新的合適的位置從而來分配新的空間。

　　這個過程需要做很多額外的操作，數據的毫無順序會導致數據分布散亂，將會導致以下的問題：

　　①寫入的目標頁很可能已經刷新到磁盤上並且從緩存上移除，或者還沒有被加載到緩存中，innodb 在插入之前不得不先找到並從磁盤讀取目標頁到內存中，這將導致大量的隨機 IO。
　　②因為寫入是亂序的，innodb 不得不頻繁的做頁分裂操作，以便為新的行分配空間，頁分裂導致移動大量的數據，一次插入最少需要修改三個頁以上。
　　③由於頻繁的頁分裂，頁會變得稀疏並被不規則的填充，最終會導致數據會有碎片。

　　在把隨機值（uuid 和雪花 id）載入到聚簇索引（InnoDB 默認的索引類型）以后，有時候會需要做一次 OPTIMEIZE TABLE 來重建表並優化頁的填充，這將又需要一定的時間消耗。

　　結論：使用 InnoDB 應該盡可能的按主鍵的自增順序插入，並且盡可能使用單調的增加的聚簇鍵的值來插入新行。