直接用UUID作Gin+GORM主键可行但必须存为BINARY(16)并用UUID_TO_BIN(UUID(), 1)写入，否则写入性能暴跌、二级索引体积翻倍；应用层应生成UUIDv1/v7并确保类型映射与字节序对齐。
直接用 uuid.UUID 作 Gin 应用的数据库主键可行，但不加处理会踩坑——尤其在 MySQL + GORM 场景下，写入性能可能暴跌 3 倍以上，二级索引体积翻倍是常态。
MySQL 中 UUID 主键必须存为 BINARY(16)，不能用 VARCHAR(36)
原始 UUID 字符串（如 "a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8"）占 36 字节，而 BINARY(16) 仅占 16 字节。InnoDB 聚簇索引把主键值和整行数据绑在一起，主键变大 → 每页能存的行数减少 → 索引层级加深 → 查询变慢。更严重的是，所有二级索引（比如 INDEX user_email）都隐式包含主键值，所以每个二级索引也跟着膨胀。
- 建表时用：
id BINARY(16) PRIMARY KEY，不是VARCHAR(36) - 插入时必须调用
UUID_TO_BIN(UUID(), 1)，第二个参数1表示“交换时间字节”，否则即使你用uuid1()生成，B+Tree 里依然无序 - 查询时反向用
BIN_TO_UUID(id, 1)转回可读字符串（仅用于调试或 API 返回，别用于 WHERE 条件）
Gin + GORM 模型中正确声明 UUID 主键字段
GORM v2 默认不识别 uuid.UUID 类型，直接写 ID uuid.UUID `gorm:"primary_key"` 会导致迁移失败或插入空值。必须显式指定底层数据库类型，并禁用默认的自增行为。
- Go 结构体字段定义：
ID uuid.UUID `gorm:"type:char(36);primary_key;not null"`—— 这是错的，字符串存储； 正确写法是：ID uuid.UUID `gorm:"type:binary(16);primaryKey;not null"` - 务必在初始化 GORM 前注册 UUID 驱动支持（如使用
github.com/google/uuid）：import "github.com/google/uuid"，并在创建记录前用uuid.New()或uuid.NewUUID()生成 - 如果用 MySQL 8.0+，推荐在应用层生成
uuid.NewTime()（对应 UUIDv1），再转成[]byte存入，避免依赖数据库函数
为什么不能依赖 MySQL 的 UUID() 函数自动填充？
MySQL 内置 UUID() 返回的是 v4 随机 UUID，高位字节无时间信息；即使配合 UUID_TO_BIN(UUID(), 1)，也只是对随机值做字节重排，无法让新值整体“追加”到 B+Tree 右侧。结果就是每次插入都触发页分裂，磁盘随机写激增。
- 现象：
SHOW ENGINE INNODB STATUS中频繁出现"Number of page splits"上升 - 替代方案：用 Go 生成 UUIDv1 或 UUIDv7（如
github.com/oklog/ulid或github.com/segmentio/kafka-go/ulid），它们天然时间前置，二进制排序即插入顺序 - 若坚持用 v4，至少在应用层批量生成后排序再插入，减少物理跳跃
真正麻烦的不是生成 UUID，而是让它在 InnoDB 里“不捣乱”。时间信息必须落在二进制表示的高位，且数据库和 ORM 层的类型映射、序列化方式必须完全对齐——漏掉任意一环，性能损耗就藏在日常的慢查询里，而不是报错时才暴露。
