mysql使用什么字段做主鍵，是重點考慮兩方面：業(yè)務(wù)場景和效率問題。在滿足業(yè)務(wù)場景的前提下，使用自增序列做主鍵是最優(yōu)選擇。原因如下：
1.自增主鍵節(jié)省存儲空間。
2.innodb的索引特性導(dǎo)致了自增id做主鍵是效率最好的
與UUID主鍵對比：
在500W記錄表的測試下：
（1） 普通單條或者20條左右的記錄檢索，uuid為主鍵的相差不大幾乎效率相同；
（2） 但是范圍查詢特別是上百成千條的記錄查詢，自增id的效率要大于uuid；
（3） 在范圍查詢做統(tǒng)計匯總的時候，自增id的效率要大于uuid；
（4） 在存儲上面，自增id所占的存儲空間是uuid的1/2；
（5） 在備份恢復(fù)上，自增ID主鍵稍微優(yōu)于UUID。
在1000W記錄表的測試下：
（1）普通單條或者20條左右的記錄檢索，自增主鍵效率是uuid主鍵的2到3倍；
（2）但是范圍查詢特別是上百成千條的記錄查詢，自增id的效率要大于uuid；
（3）在范圍查詢做統(tǒng)計匯總的時候，自增id主鍵的效率是uuid主鍵1.5到2倍；
（4）在存儲上面，自增id所占的存儲空間是uuid的1/2；
（5）在寫入上面，自增ID主鍵的效率是UUID主鍵的3到10倍，相差比較明顯，特別是update小范圍之內(nèi)的數(shù)據(jù)上面。
（6）在備份恢復(fù)上，自增ID主鍵稍微優(yōu)于UUID。
對于InnoDB這種聚集主鍵類型的引擎來說，數(shù)據(jù)會按照主鍵進(jìn)行排序，由于UUID的無序性，InnoDB會產(chǎn)生巨大的IO壓力，而且由于索引和數(shù)據(jù)存儲在一起，字符串做主鍵會造成存儲空間增大一倍。
在存儲和檢索的時候，innodb會對主鍵進(jìn)行物理排序，這對auto_increment_int是個好消息，因為后一次插入的主鍵位置總是在最后。但是對uuid來說，這卻是個壞消息，因為uuid是雜亂無章的，每次插入的主鍵位置是不確定的，可能在開頭，也可能在中間，在進(jìn)行主鍵物理排序的時候，勢必會造成大量的 IO操作影響效率，在數(shù)據(jù)量不停增長的時候，特別是數(shù)據(jù)量上了千萬記錄的時候，讀寫性能下降的非常厲害。
總結(jié)：
（1）單實例或者單節(jié)點組：
經(jīng)過500W、1000W的單機(jī)表測試，自增ID相對UUID來說，自增ID主鍵性能高于UUID，磁盤存儲費用比UUID節(jié)省一半的錢。所以在單實例上或者單節(jié)點組上，使用自增ID作為首選主鍵。
（2）分布式架構(gòu)場景：
20個節(jié)點組下的小型規(guī)模的分布式場景，為了快速實現(xiàn)部署，可以采用多花存儲費用、犧牲部分性能而使用UUID主鍵快速部署；
20到200個節(jié)點組的中等規(guī)模的分布式場景，可以采用自增ID+步長的較快速方案。
200以上節(jié)點組的大數(shù)據(jù)下的分布式場景，可以借鑒類似twitter雪花算法構(gòu)造的全局自增ID作為主鍵