為啥不能用uuid做MySQL的主鍵？
在 MySQL 中設計表的時候，MySQL 官方推薦不要使用 uuid 或者不連續(xù)不重復的雪花 id（long 形且唯一，單機遞增），而是推薦連續(xù)自增的主鍵 id，官方的推薦是 auto_increment。
那么為什么不建議采用 uuid，使用 uuid 究竟有什么壞處？本問我們從以下幾個部分來分析這個問題，探討一下內(nèi)部的原因：
MySQL 程序實例
使用 uuid 和自增 id 的索引結構對比
總結
MySQL 程序實例
要說明這個問題，我們首先來建立三張表，分別是：
user_auto_key
user_uuid
user_random_key
他們分別表示自動增長的主鍵，uuid 作為主鍵，隨機 key 作為主鍵，其他我們完全保持不變。
id 自動生成表：
用戶 uuid 表：
光有理論不行，直接上程序，使用 Spring 的 jdbcTemplate 來實現(xiàn)增查測試。
技術框架：Spring Boot+jdbcTemplate+junit+hutool，程序的原理就是連接自己的測試數(shù)據(jù)庫，然后在相同的環(huán)境下寫入同等數(shù)量的數(shù)據(jù)，來分析一下 insert 插入的時間來進行綜合其效率。
package?com.wyq.mysqldemo;
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("執(zhí)行sql時間消耗");
????????/**
?????????*?auto_increment?key任務
?????????*/
????????final?String?insertSql?=?"INSERT?INTO?user_key_auto(user_id,user_name,sex,address,city,email,state)?VALUES(?,?,?,?,?,?,?)";
????????List?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?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?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);
????}
程序寫入結果
user_key_auto 寫入結果：
user_random_key 寫入結果：
user_uuid 表寫入結果：
效率測試結果
在已有數(shù)據(jù)量為 130W 的時候：我們再來測試一下插入 10w 數(shù)據(jù)，看看會有什么結果：
可以看出在數(shù)據(jù)量 100W 左右的時候，uuid 的插入效率墊底，并且在后序增加了 130W 的數(shù)據(jù)，uuid 的時間又直線下降。
時間占用量總體可以打出的效率排名為：auto_key>random_key>uuid。
uuid 的效率最低，在數(shù)據(jù)量較大的情況下，效率直線下滑。那么為什么會出現(xiàn)這樣的現(xiàn)象呢？帶著疑問,我們來探討一下這個問題：
使用 uuid 和自增 id 的索引結構對比
使用自增 id 的內(nèi)部結構
自增的主鍵的值是順序的，所以 InnoDB 把每一條記錄都存儲在一條記錄的后面。
當達到頁面的最大填充因子時候（InnoDB 默認的最大填充因子是頁大小的 15/16，會留出 1/16 的空間留作以后的修改）。
使用 uuid 的索引內(nèi)部結構
使用自增 id 的缺點
那么使用自增的 id 就完全沒有壞處了嗎？并不是，自增 id 也會存在以下幾點問題：
①別人一旦爬取你的數(shù)據(jù)庫，就可以根據(jù)數(shù)據(jù)庫的自增 id 獲取到你的業(yè)務增長信息，很容易分析出你的經(jīng)營情況。
②對于高并發(fā)的負載，InnoDB 在按主鍵進行插入的時候會造成明顯的鎖爭用，主鍵的上界會成為爭搶的熱點，因為所有的插入都發(fā)生在這里，并發(fā)插入會導致間隙鎖競爭。
③Auto_Increment 鎖機制會造成自增鎖的搶奪，有一定的性能損失。
附：Auto_increment的鎖爭搶問題，如果要改善需要調(diào)優(yōu) innodb_autoinc_lock_mode 的配置。
總結
-END-
近期熱門推薦? 1.今天跟大家聊聊 Spring Security 的前世今生
2.為什么建議大家使用 Linux 開發(fā)？爽（外加七個感嘆號）
3.為什么 Java 中“1000==1000”為false，而”100==100“為true？
4.我去頭條面試，面試官問我如何設計好API，看看我是如何吊打面試官的！
6.一個依賴搞定 Spring Boot 反爬蟲，防止接口盜刷！
7.Springboot啟動擴展點超詳細總結，再也不怕面試官問了
如有文章對你有幫助，
在看和轉發(fā)是對我最大的支持！
關注Java開發(fā)寶典
每天學習技術干貨
點贊是最大的支持?
