Mysql選擇主鍵

對於乙個表來說主鍵選用的好壞直接關係到對於該錶的操作效能，因此主鍵選用的好壞很大程度上決定了表的相關效能。一般來說選用主鍵需要遵循以下規則：

int型別在做比較運算時會獲取更好的效能（cpu比較週期縮短）。

int型別是順序排列的這樣在索引中邏輯上相鄰的資料就分布在磁碟相鄰的地方（大大減少io次數）

主鍵長度盡可能短。如果選用bigint做主鍵由於bigint做主鍵只佔8個位元組所以比較節約空間，同時查詢效能也很好。

字串來做主鍵，myisam預設的情況下為字串使用了壓縮索引這使查詢更加緩慢。

他們會減慢insert查詢，因為插入的值會被隨機放入索引頁中，導致分頁，隨機磁碟訪問及聚集儲存引擎的聚集索引碎片。

他們會減慢查詢速度，因為邏輯上相鄰的行會分布在磁碟和記憶體中的各個地方。

隨機值會導致快取對所有型別的查詢效能都很差，因為他們會使快取依賴以工作的訪問區域性性失效，如果整個資料集都變的同樣「熱」的時候，那麼把特定部分的資料快取到記憶體中就沒有任何優勢了。並且如果工作集部能被裝入記憶體中，快取就會進行很多刷寫的工作，並且會導致很多快取未命中。

myisam 引擎支援和聚集索引（主要是b樹索引），不支援聚集索引。

innodb 引擎支援聚集索引，非聚集索引（主要是b樹索引，hash索引）。

因此對於不支援聚集索引的myisam來說即使建立了主鍵也是不能為其建立聚集索引的，因此資料的物理排列順序則是插入資料先後的順序（myisam插入資料時是直接插入表的尾部的）。雖然資料是插入在表的尾部但是對於索引來說隨機的主鍵值則是按一定的規則進行排列的。這樣隨機主鍵就容易導致索引頻繁分頁，進而出現索引碎片，最終導致insert慢select查詢慢。

對於innodb來說我們可以為主鍵建立聚集索引，聚集索引儲存記錄是物理上連續存在的。因此insert時插入排序規則(uuid_short())的值做主鍵可以直接將該值追加到表的尾部，且索引沒有發生分頁。更重要的是對於聚集索引來說索引下面直接對應的就是資料因此按主鍵查詢時效率會比myisam要高很多。（myisam索引下面對應的是指向資料的乙個指標）

單純對於myisam來說在選用主鍵型別時也是要避免使用字串的。因為myisam上的字串型別所建立的索引預設採用的是壓縮處理後的格式，因此在查詢時效率要稍慢一些。

uuid_short() pk uuid()

uuid()：用來生成唯一值該值型別為string長度為32位且為無序的值（所謂無序的值是指每次生成的值沒有規律可言或者說是隨機的），這決定了他不能做主鍵

select uuid();
fe534759-be25-11e4-ba95-4437e64f803e

uuid_short()：用來生成唯一值（理論上也是有限的但是由於出現出現重複的概率低到了極致或者說出現的概率最大為1/1000000000000000(以最低生成位數來算，實際生成位數一般都大於16)），跟uuid()相比uuid_short()生成的是有序的整數，長度在16-21（或者更長）位之間，如果我們用bigint來儲存處理後的uuid_short()作為主鍵是完全符合主鍵的選取規則的。

select uuid_short();
23906203910275154

與uuid返回固定長度字串不同， uuid_short的返回值是乙個unsigned long long型別。mysql啟動後第一次執行的值是通過server_id << 56 + server_start_time << 24來初始化。server_start_time單位是秒。之後每次執行都加1。

由於每次加1都會加全域性mutex鎖，因此多執行緒安全，可以當作sequence來用，只是初始值有點大。

sequence

mysql沒有oracle那樣的sequence，在不是很精確的情況下，可以考慮上面提到的uuid_short。有一些不足:

1、初始值太大，無法重設

2、存在乙個問題是每次重啟後第一次執行的值不是重啟前的那個值+1

3、而且如果重啟在1s內完成，可能出現不單調遞增（雖然這個可能性微乎其微）。

Mysql選擇主鍵

Mysql選擇主鍵

mysql 主鍵選擇

設計套路 Mysql主鍵的選擇

Mysql選擇主鍵

Mysql選擇主鍵

mysql 主鍵選擇

設計套路 Mysql主鍵的選擇

相關推薦