MYSQL主鍵政策（自增，UUid，雪花算法）

作為一個快要大四的學生，mysql的主鍵政策到底怎麼選用一直很疑惑，平時也會查閱一些資料，但都沒有整合思考過，今天趁着有時間就寫一寫我知道的一些東西。

自增的優點：

1.存儲空間小

2.插入和查詢性能高

自增的缺點：

1.int的範圍可能不夠大（但我覺得等資料到上億級别，大部分情況下都要做分庫分表了吧…）

2.當要做資料遷移的時候，會很麻煩，主鍵容易沖突

3.id自增，自身的業務增長情況很容易被别人掌握

4.自增在高并發的情況下性能不好

UUid的優點：

1.獨一無二，幾乎不會重複

2.資料合并很友善（主鍵不會沖突）

3.業務增長資料不會被輕易察覺

UUid的缺點：

1.生成UUid花的時間比較多

2.存儲空間大

3.資料庫存儲UUid作為主鍵花的時間很多，消耗的性能也很多

自增和UUid差異的原因

mysql資料庫一般我們會采用支援事務的Innodb，在Innodb中，采用的是B+數索引。Innodb的存儲結構，是聚簇索引。對于聚簇索引順序主鍵和随機主鍵的對效率的影響很大。

自增是順序主鍵存儲，查找和插入都很友善（插入會按順序插到前一個的後面），但UUid是無序的，通過計算獲得的hashcode也會是無序的（是按照hashcode選擇存儲位置）是以對于他的查找效率很低，而且因為他是無序的，他的插入有可能會插到前面的資料中，會造成很多其他的操作，很影響性能或者很多存儲空間因為沒有順序的存儲而被空缺浪費。

是以對于選用哪種政策，還是要看具體情況進行選擇，我一般會使用雪花算法（snowflake）。

雪花算法：

大概是由時間戳+機器碼+同一時間的自增組成的。

是以他會有以下優點：

1.不會重複

2.有序，不會造成空間浪費和胡亂插入影響性能

3.生成很快特别是比UUid快的多

4.相比UUid更小

當然了雪花算法也有缺點：時間回撥造成錯亂

以下是雪花算法和UUid分别生成1000000（一百萬）個id的時間對比：

首先是生成id的代碼

import java.util.UUID;

public class HelloWord {

    public static void main(String[] args)  {
        SnowflakeIdWorker idWorker=new SnowflakeIdWorker(0,0);
        /**
         *雪花算法
            * @return void
            * @author tzj
            * @date 2020/8/21 15:17
        */
        long start=System.currentTimeMillis();
        for(int i=0;i<1000000;i++){
            long id=idWorker.nextId();
        }
        long end=System.currentTimeMillis();
        System.out.println("生成1000000個id用時： "+(end-start)+" ms");
        /**
         *UUid
            * @return void
            * @author 這裡寫自己想展示的作者名
            * @date 2020/8/21 15:18
        */
        long startUUid=System.currentTimeMillis();
        for(int i=0;i<1000000;i++){
            UUID uuid=UUID.randomUUID();
        }
        long endUUid=System.currentTimeMillis();
        System.out.println("生成1000000個UUid用時： "+(endUUid-startUUid)+" ms");
    }


}

           

SnowflakeIdWorker是生成雪花算法id的工具類。

接下來是結果