-- 自增主键
CREATE TABLE user_auto (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(50)
);

-- UUID 主键
CREATE TABLE user_uuid (
    id CHAR(36) PRIMARY KEY,
    name VARCHAR(50)
);

B+树结构（顺序写入）：
[1] → [2] → [3] → [4] → [5] → ...
                         ↑ 新记录直接追加

自增 BIGINT：8 字节
UUID CHAR(36)：36 字节（甚至更多）

二级索引主键占用：
自增 → 每个二级索引存 8 字节
UUID → 每个二级索引存 36 字节

应用层生成 ID，无需依赖数据库：
- 分库分表不会冲突
- 合并数据不用处理 ID 冲突
- 多库独立生成，无中心瓶颈

自增暴露问题：
/user/1000  → 可推测过去有 999 条记录
/user/10000 → 每天约 9000 增长，可反推业务量

UUID 暴露问题：
/a1b2c3d4-... → 猜不出任何信息

-- 自增在高并发下：
INSERT INTO t (name) VALUES ('A');  -- 等待自增锁
INSERT INTO t (name) VALUES ('B');  -- 排队
-- InnoDB 的 AUTO-INC 锁可能成为热点

-- UUID 直接生成，无锁竞争：
INSERT INTO t (id, name) VALUES (UUID(), 'A');
INSERT INTO t (id, name) VALUES (UUID(), 'B');

B+树结构（随机写入）：
[1] [5] [9] [3] [7] [2] ...
插入 6 → 在第 2 页和第 3 页之间 → 页分裂！
插入 4 → 在第 1 页和第 2 页之间 → 页分裂！

1000 万条数据：

自增 BIGINT：        80 MB（主键）
UUID CHAR(36)：     360 MB（主键）
+ 二级索引中复制的 UUID → 总空间差距数倍

SELECT UUID_TO_BIN(UUID(), true);
-- 生成 time-ordered 二进制 UUID

-- 业务生成 64 位长整型
-- 时间戳(41) + 机器ID(10) + 序列号(12)
-- 有序递增，8 字节，分布式唯一

-- 自增主键(内部) + UUID(业务)
CREATE TABLE t (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,   -- 内部关联用
    biz_id CHAR(36) UNIQUE,                 -- 对外暴露
    UNIQUE INDEX uk_biz_id(biz_id)
);

-- 1. 迁移麻烦：多库合并 ID 冲突
-- 库A 最后 ID：1000
-- 库B 最后 ID：1000
-- 合并后：ID 重复！

-- 2. 数据暴露
SELECT * FROM user ORDER BY id DESC LIMIT 1;
-- 今天 10000，明天 15000 → 每天 5000 新增

-- 3. 跳号问题
INSERT ... ROLLBACK;  -- ID 被占用但回滚，不会重用
-- ID 序列：1, 2, 3, 4 (3被回滚了), 5, 6...

自增主键：数据库生成 → 写入后才能获取 ID
UUID：    应用生成 → 先有 ID 再写入

影响：
- 自增：需要写回才能拿到 ID，可能要多一次查询
- UUID：可以在代码里预先组装对象，写的时候直接 INSERT