mysql InnoDB UUID 主鍵性能優化【原理篇】.md

時間 2019-11-06

標籤 mysql innodb uuid 性能優化原理篇欄目 MySQL 简体版

原文原文鏈接

mysql InnoDB uuid 主鍵性能優化【原理篇】.md mysql InnoDB UUID 主鍵性能優化【實踐篇】.md 有序uuid mysql InnoDB UUID 主鍵性能優化【原理篇】.md mysql InnoDB UUID 主鍵性能優化【性能分析篇】.mdjava

##1. mysql InnoDB 表主鍵用uuid仍是int類型的自增序列？mysql

主鍵大多場景仍是自增序列類型，效率高 1.自增序列簡單，存儲空間效率高適合簡單的管理系統；單庫環境分庫處理麻煩一下；須要配置offset，數據整合複雜redis

2.uuid 一些場景，更適合uuid 分庫分表：UUID支持對錶進行水平劃分，將數據分佈存儲在多臺不一樣的機器上，動態擴縮容。內存生成對象，對象id在內存作關聯運算時，可使用uuid或分佈式int id；【若是用序列，須要和db通訊後，才能獲取id；】數據通過多個server處理後，才入庫；如分佈式發現資源、子資源，集中入庫；dcs產生數據、ccs入庫算法

3.分佈式id 自定義int類型主鍵生成算法；用分佈式int類型的id，如redis產生idsql

本文針對uuid使用進行優化性能優化

##2.UUID ###2.1UUID概念 UUID(Universally Unique Identifier)全局惟一標識符,是指在一臺機器上生成的數字，它保證對在同一時空中的全部機器都是惟一的分佈式

UUID是16字節128位長的數字，一般以36字節的字符串表示，示例以下：
f5a96171-0045-11e5-9cc7-fcaa1490706f 其中的字母是16進製表示，大小寫無關。
uuid36位去掉- 爲32位

###2.1UUID排序性能

標準的UUID格式爲：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (8-4-4-4-12) UUID組成：優化

（1）當前日期和時間，UUID的第一個部分與時間有關，若是你在生成一個UUID以後，過幾秒又生成一個UUID，則第一個部分不一樣，其他相同。
（2）時鐘序列。
（3）全局惟一的IEEE機器識別號，若是有網卡，從網卡MAC地址得到，沒有網卡以其餘方式得到。

要想每次生成的uuid有序，就須要把時間放後，機器碼提早。排序示例ui

原始uuid    22886ea0-0048-11e5-9e24-fcaa1490706f    轉換後    11e5-0048-9e24-fcaa1490706f-22886ea0
原始uuid    229c92e1-0048-11e5-9e24-fcaa1490706f    轉換後    11e5-0048-9e24-fcaa1490706f-229c92e1

###2.3JAVA 的UUID

Java UUID Generator (JUG)：開源UUID生成器，LGPL協議，支持MAC地址。
java 自帶uuid

##3.爲何須要UUID有序

###3.1InnoDB引擎表的一些關鍵特徵

InnoDB引擎表是基於B+樹的索引組織表(IOT)；
每一個表都須要有一個彙集索引(clustered index)；
全部的行記錄都存儲在B+樹的葉子節點(leaf pages of the tree)；
基於彙集索引的增、刪、改、查的效率相對是最高的；
若是咱們定義了主鍵(PRIMARY KEY)，那麼InnoDB會選擇其做爲彙集索引；
若是沒有顯式定義主鍵，則InnoDB會選擇第一個不包含有NULL值的惟一索引做爲主鍵索引；
若是也沒有這樣的惟一索引，則InnoDB會選擇內置6字節長的ROWID做爲隱含的彙集索引(ROWID隨着行記錄的寫入而主鍵遞增，這個ROWID不像ORACLE的ROWID那樣可引用，是隱含的)。

綜上總結，若是InnoDB表的數據寫入順序能和B+樹索引的葉子節點順序一致的話，這時候存取效率是最高的. 自增序列效率高的緣由；uuid無序，就要想辦法使其相對有序。

###3.2MySQL聚簇索引 MySQL聚簇索引保證關鍵字的值相近的元組存儲的物理位置也相同（因此隨機字符串，會使得系統進行大量的移動操做），且一個表只能有一個聚簇索引。由於由存儲引擎實現索引，因此，並非全部的引擎都支持聚簇索引。目前，只有solidDB和InnoDB支持。　　聚簇索引的結構大體以下：