最近研究uuid，收集的一些資料：
mysql uuid函式的詳解
mysql中可以有二類用於生成唯一值性質的工具：uuid()函式和自增序列，那麼二者有何區別呢？我們就此對比下各自的特性及異同點：uuid做主鍵，好還是不好？這是個問題。l 都可以實現生成唯一值的功能；
l uuid是可以生成時間、空間上都獨一無二的值；自增序列只能生成基於表內的唯
一值，且需要搭配使其為唯一的主鍵或唯一索引；
l 實現方式不一樣，uuid是隨機+規則組合而成的，而自增序列是控制乙個值逐步增長的；
l uuid產生的是字串型別值，固定長度為：36個字元，而自增序列產生的是整數型別值，長度由欄位定義屬性決定；
接下來，詳細講解下uuid()函式產生的值：
oot@localhost : (none) 06:09:40> select uuid(),uuid(),length(uuid()),char_length(uuid())\g
*************************** 1. row ***************************
uuid(): de7ee638-4322-11e0-85ab-842b2b4a7e75
uuid(): de7ee642-4322-11e0-85ab-842b2b4a7e75
length(uuid()): 36
char_length(uuid()): 36
1 row in set (0.00 sec)
從上面的執行結果部分的資訊看：
l 同乙個sql語句中，多處呼叫uuid()函式得到的值不相同；
l 得到的隨機值由5個部分組成，且分隔符位為：中劃線；
l 多次呼叫或執行得到的後2組值相同，若把mysqld伺服器關閉，重新啟動之後，會發現第四組的組與未重啟前的值發生變化，然後一直不變化，只要重新啟動mysqld服務就會發生變化。另外，對於同一臺機器，第五組值始終不會發生變化；
l 字元個數為：36，佔位元組數為：36（注：系統預設字符集編碼：utf8）；
針對uuid產生的值組成部分，作如下解說：
l 前三組值是時間戳換算過來的；
l 第四組值是暫時性保持時間戳的唯一性。例如，使用夏令時；
l 第五組值是乙個iee 802的節點標識值，它是空間上唯一的。若後者不可用，則用乙個隨機數字替換。假如主機沒有網絡卡，或者我們不知道如何在某系統下獲得機器位址，則空間唯一性就不能得到保證，即使這楊，出現重複值的機率還是非常小的。
uuid函式對複製的支援：
uuid函式屬於不確定性函式，為此不支援mysql 複製的statement模式，但是支援mixed、row二種模式，大家可以設定2組測試模式，以5.1.系列版本為例。
測試基於命令列模式複製：
tx_isolation = repeatable-read
binlog_format = statement
測試基於命令列/混合模式複製：
tx_isolation = repeatable-read
binlog_format = mixed or row
在主伺服器上執行同乙個sql語句：
insert into test_uuid(username) values(uuid());
然後再比對主從伺服器上表中儲存的值，會發現基於命令列模式的：主從不一致，基於行/混合模式的：主從資料時一致；
建議：在複製模式下，需要用到uuid()函式，則一定要使用基於行/混合模式複製方式。
名詞解釋：
對於輸入引數相同，且同一時間執行或乙個sql中多處呼叫，而得到不同值得函式，我們就稱其為：不確定性函式。
備註：
在mysql 5.1.*及更高版本有乙個變種的uuid()函式，名稱：uuid_short()，生成乙個64位無符號的整數，例如：
root@localhost : (none) 02:46:42> select uuid_short()\g
*************************** 1. row ***************************
uuid_short(): 6218676250261585921
1 row in set (0.00 sec)
後續加註：
uuid()函式產生的值，並不適合作為innodb引擎表的主鍵，至於詳細的原因，請閱讀文章innodb引擎表的主鍵選型。
Mysql選擇主鍵
對於乙個表來說主鍵選用的好壞直接關係到對於該錶的操作效能，因此主鍵選用的好壞很大程度上決定了表的相關效能。一般來說選用主鍵需要遵循以下規則 int型別在做比較運算時會獲取更好的效能 cpu比較週期縮短 int型別是順序排列的這樣在索引中邏輯上相鄰的資料就分布在磁碟相鄰的地方 大大減少io次數 主鍵長...
Mysql選擇主鍵
對於乙個表來說主鍵選用的好壞直接關係到對於該錶的操作效能，因此主鍵選用的好壞很大程度上決定了表的相關效能。一般來說選用主鍵需要遵循以下規則 int型別在做比較運算時會獲取更好的效能 cpu比較週期縮短 int型別是順序排列的這樣在索引中邏輯上相鄰的資料就分布在磁碟相鄰的地方 大大減少io次數 主鍵長...
設計套路 Mysql主鍵的選擇
建表在日常開發中必不可少，但設計出來的表卻千差萬別，前期表單設計得不好，對後期維護和優化都會產生非常大的阻力，那麼我們需要如何優雅地建立我們的主鍵呢？下面我們慢慢道來 mysql是由b 樹構成，搞清楚下面兩個問題，就知道為什麼用b 樹了。1.b tree是為磁碟或者其他直接訪問輔助裝置而設計的一種平...