MySQL操作GUID，char(36)與binary(16)互轉

MySQL中GUID與binary(16)互轉函數

DELIMITER $$ -- 定義語句結束分隔符為$$
-- 將以36個字符表示的GUID值轉換為16個二進制字節表示
CREATE FUNCTION fnGuid2Binary($Data VARCHAR(36)) RETURNS binary(16)
BEGIN
  RETURN CONCAT(UNHEX(LEFT($Data,8)),UNHEX(MID($Data,10,4)),UNHEX(MID($Data,15,4)),UNHEX(MID($Data,20,4)),UNHEX(RIGHT($Data,12)));
END
$$


-- 將以16個二進制字節表示的GUID值轉換為36個字符表示
CREATE FUNCTION fnBinary2Guid($Data BINARY(16)) RETURNS char(36)
BEGIN
  RETURN CONCAT(HEX(LEFT($Data,4)),'-', HEX(MID($Data,5,2)),'-', HEX(MID($Data,7,2)),'-',HEX(MID($Data,9,2)),'-',HEX(RIGHT($Data,6)));
END
$$

 

COMB數據類型的基本設計思路是這樣的：既然UniqueIdentifier數據因毫無規律可言造成索引效率低下，影響了系統的性能，那么我們能不能 通過組合的方式，保留UniqueIdentifier的前10個字節，用后6個字節表示GUID生成的時間（DateTime），這樣我們將時間信息與 UniqueIdentifier組合起來，在保留UniqueIdentifier的唯一性的同時增加了有序性，以此來提高索引效率。也許有人會擔心 UniqueIdentifier減少到10字節會造成數據出現重復，其實不用擔心，后6字節的時間精度可以達到1/300秒，兩個COMB類型數據完全 相同的可能性是在這1/300秒內生成的兩個GUID前10個字節完全相同，這幾乎是不可能的！

但是MySQL中並沒有原生支持GUID類型，所以只能使用binary(16)來存放GUID值，但是GUID值的高位是放在尾部的，如此一來轉換為binary(16)后就無法利用高位來排序了。

所以寫了下面兩個函數，來實現COMB類型與binary(16)互轉

DELIMITER $$ -- 定義語句結束分隔符為$$
-- 將以36個字符表示的GUID值(其中高6位為時間信息，用於排序)轉換為16個二進制字節表示
CREATE FUNCTION fnCOMB2Binary($Data VARCHAR(36)) RETURNS binary(16)
BEGIN
  -- 特別注意：表示GUID的文本中最后12個字符為高6位的十六進制文本，這里特別將其提到最前是為了便於利用該值排序
  RETURN CONCAT(UNHEX(RIGHT($Data,12))/*將高6位提到最前*/,UNHEX(LEFT($Data,8)),UNHEX(MID($Data,10,4)),UNHEX(MID($Data,15,4)),UNHEX(MID($Data,20,4)));
END
$$


-- 將以16個二進制字節表示的GUID值(其中高6位為時間信息，用於排序)轉換為36個字符表示
CREATE FUNCTION fnBinary2COMB($Data BINARY(16)) RETURNS char(36)
BEGIN
  -- 特別注意：表示COMB值的二進制數組中前6位對應GUID文本中最后12個十六進制文本，在還原時注意拼接的先后順序
  RETURN CONCAT(HEX(MID($Data,7,4)),'-', HEX(MID($Data,11,2)),'-', HEX(MID($Data,13,2)),'-',HEX(MID($Data,15,2)),'-',HEX(LEFT($Data,6)));
END
$$