引用
一、主鍵設計原則
- MySQL主鍵應當是對用戶沒有意義的。
- MySQL主鍵應該是單列的，以便提高連接和篩選操作的效率
- 永遠也不要更新MySQL主鍵
- MySQL主鍵不應包含動態變化的數據，如時間戳、創建時間列、修改時間列等
- MySQL主鍵應當有計算機自動生成
二、主鍵選取原則
主鍵是一個索引，mysql的索引是B+樹，Mysql會按照鍵值的大小進行順序存放，如果我們設置自增id為主鍵，這個時候主鍵是按照一種緊湊的接近順序寫入的方式進行存儲數據。如果我們用其他字段作為主鍵的話，此時Mysql不得不為了將新記錄插到合適位置而移動數據，甚至目標頁面可能已經被回寫到磁盤上而從緩存中清掉，此時又要從磁盤上讀回來，這增加了很多額外的開銷，同時頻繁的移動、分頁操作造成了大量的碎片。
- 考慮性能消耗
- 考慮資源消耗
- 考慮分庫分表
三、主鍵類型的選擇
-
整數類型
整數類型往往是id列最好的選擇，因為效率最高并且可以使用數據庫的自增主鍵。 -
字符串類型
字符串類型相比整數類型肯定更消耗空間，也會比整數類型操作慢。我主要使用的是Mysql，關于這個話題的解釋建議看《高性能MySQL》第三版 P125。
四、主鍵設計的常用方案
- 非分布式架構直接套用自增id做主鍵
- 小規模分布式架構用uuid或者自增id+步長做主鍵
- 大規模分布式架構用自建的id生成器做主鍵，參考twitter的[snowflake算法][2]
1、自增ID
優點
1、數據庫自動編號，速度快，而且是增量增長，聚集型主鍵按順序存放，對于檢索非常有利；
2、 數字型，占用空間小，易排序，在程序中傳遞方便。-
缺點
1、不支持水平分片架構，水平分片的設計當中，這種方法顯然不能保證全局唯一；
2、表鎖；在MySQL5.1.22之前，InnoDB自增值是通過其本身的自增長計數器來獲取值，該實現方式是通過表鎖機制來完成的（AUTO-INC LOCKING）。鎖不是在每次事務完成后釋放，而是在完成對自增長值插入的SQL語句后釋放，要等待其釋放才能進行后續操作。比如說當表里有一個auto_increment字段的時候，innoDB會在內存里保存一個計數器用來記錄auto_increment的值，當插入一個新行數據時，就會用一個表鎖來鎖住這個計數器，直到插入結束。如果大量的并發插入，表鎖會引起SQL堵塞。
在5.1.22之后，InnoDB為了解決自增主鍵鎖表的問題，引入了參數innodb_autoinc_lock_mode：
0：通過表鎖的方式進行，也就是所有類型的insert都用AUTO-inc locking（表鎖機制）。
1：默認值，對于simple insert 自增長值的產生使用互斥量對內存中的計數器進行累加操作，對于bulk insert 則還是使用表鎖的方式進行。
2：對所有的insert-like 自增長值的產生使用互斥量機制完成，性能最高，并發插入可能導致自增值不連續，可能會導致Statement 的 Replication 出現不一致，使用該模式，需要用 Row Replication的模式。3、自增主鍵不連續。
CREATE TABLE `tmp_auto_inc` ( `id` int(11) NOT NULL AUTO_INCREMENT, `talkid` int(11) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=16 DEFAULT CHARSET=gbk;當插入10條記錄的時候，因為AUTO_INCREMENT=16，所以下次再插入的時候，主鍵就會不連續。
2、UUID
優點
1、全局唯一性、安全性、可移植性。
2、能夠保證獨立性，程序可以在不同的數據庫間遷移，效果不受影響。
3、保證生成的ID不僅是表獨立的，而且是庫獨立的，在你切分數據庫的時候尤為重要缺點
1、針對InnoDB引擎會徒增IO壓力，InnoDB為聚集主鍵類型的引擎，數據會按照主鍵進行排序，由于UUID的無序性，InnoDB會產生巨大的IO壓力。InnoDB主鍵索引和數據存儲位置相關（簇類索引），uuid 主鍵可能會引起數據位置頻繁變動，嚴重影響性能。
2、UUID長度過長，一個UUID占用128個比特（16個字節）。主鍵索引KeyLength長度過大，而影響能夠基于內存的索引記錄數量，進而影響基于內存的索引命中率，而基于硬盤進行索引查詢性能很差。嚴重影響數據庫服務器整體的性能表現。
