// UUID內部表示為16字節(jié)的二進制數(shù)據(jù)
// 比較規(guī)則：從左到右按字節(jié)比較
// 示例UUID比較：
UUID1: 1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
UUID2: 6d5c5a5e-5c5a-4e5a-8d5a-5a5e5c5a5e5c
// 比較過程：
// 第一個字節(jié)：0x1a vs 0x6d → UUID1 < UUID2
// 因為 0x1a = 26, 0x6d = 109
注意： UUID 視為連續(xù)的 16 個字節(jié), UUID1 的字節(jié)序
列（十六進制）：1a 2b 3c 4d 5e 6f 7a 8b 9c 0d 1e 2f 3a 4b 5c 6d 
0x1a中前面0x表示16進制。其實就基本上可以理解每個字符對比，從左到右依次對比。

比如B+tree中已經(jīng)存在一個字符是B的節(jié)點，因為UUID生成是隨機的可能生成了一個A，
可能生成了一個C，那么A就會插入到B的前面，前面的樹都排好的，A一插入就會導致樹結構
需要重排。但是自增ID或者順序插入，不會影響B(tài)+tree的問題。

1、順序寫入
-- 假設B+Tree的葉子節(jié)點容量為3條記錄
-- 當前數(shù)據(jù)頁狀態(tài)：
頁1: [1, 2, 3]    -- 已滿
頁2: [4, 5, 6]    -- 已滿  
頁3: [7, 8]       -- 有空間
-- 插入新記錄：id = 9
-- 過程：直接追加到頁3 → [7, 8, 9] ?
-- 無頁分裂，性能極佳

-- 同樣的B+Tree，使用UUID主鍵
-- 當前數(shù)據(jù)頁狀態(tài)（按UUID排序）：
頁1: [uuid_a, uuid_c, uuid_f]    -- 已滿
頁2: [uuid_h, uuid_m, uuid_p]    -- 已滿
頁3: [uuid_r, uuid_z]            -- 有空間
-- 插入新記錄：uuid_k（隨機生成）
-- 需要找到插入位置：在uuid_h和uuid_m之間
-- 但頁2已滿！觸發(fā)頁分裂過程

// 前8字節(jié)：當前時間戳（毫秒）+ 后8字節(jié)：隨機數(shù)，確保同一毫秒內的唯一性
long timestamp = System.currentTimeMillis();
bb.putLong(timestamp);

-- 初始狀態(tài)：B+Tree葉子節(jié)點
頁1: [1, 3, 5]    -- 已用空間 100%
頁2: [7, 9, 11]   -- 已用空間 100%
頁3: [13, 15]     -- 已用空間 66%
-- 刪除中間數(shù)據(jù)：刪除記錄 7
頁2: [9, 11]      -- 已用空間 66%，有剩余空間
-- 刪除不會導致分裂，反而可能觸發(fā)合并?。ó旐摰氖褂寐实陀?0%時，觸發(fā)頁合并）

1、刪除操作的惰性處理
-- InnoDB不會立即進行頁合并，而是：
-- 1. 標記記錄為已刪除（邏輯刪除）
-- 2. 在后臺由purge線程清理
-- 3. 在合適時機進行頁合并
-- 查看刪除狀態(tài)
SHOW ENGINE INNODB STATUS;
-- 在輸出中查找 "PHYSICAL DELETES" 和 "LOGICAL DELETES"