MySQL UUID_TO_BIN 如何保持时间有序：swap_flag 与 BIN_TO_UUID 还原边界

把 UUID 从 CHAR(36) 改成 BINARY(16) 后，真正容易出错的不是字段类型，而是读写两端对 swap_flag 的约定。写入时用 UUID_TO_BIN(uuid, 1)，读取就要用 BIN_TO_UUID(id, 1)；只要一边漏掉这个参数，得到的字符串仍像 UUID，却已经不是原值。

先看一个最小可验证结果

MySQL 官方文档把 UUID_TO_BIN() 的第二个参数定义为交换开关：传入 0 时保持原顺序，传入 1 时交换 time-low 与 time-high。下面固定一个 version 1 UUID，避免使用随机值让读者无法复核：

SET @uuid = '6ccd780c-baba-1026-9564-5b8c656024db';
SELECT @uuid AS source_uuid,
       HEX(UUID_TO_BIN(@uuid, 0)) AS no_swap_hex,
       HEX(UUID_TO_BIN(@uuid, 1)) AS swapped_hex,
       BIN_TO_UUID(UUID_TO_BIN(@uuid, 1), 1) AS round_trip_uuid,
       BIN_TO_UUID(UUID_TO_BIN(@uuid, 1), 0) AS wrong_flag_uuid;

输出中最值得关注的是两列 HEX：未交换时以 6CCD780CBABA... 开头，交换后变成 1026BABA6CCD...。这不是编码损坏，而是为了让 version 1 UUID 中变化更快的时间部分移动到更适合索引比较的位置。

swap_flag 到底交换了哪一段

UUID 字符串通常按五组十六进制显示。对上面的值，6ccd780c 是 time-low，baba 是 time-mid，1026 是 time-high。UUID_TO_BIN(@uuid, 1) 把第三组和第一组交换，二进制结果因此从：

6CCD780C BABA 1026 9564 5B8C656024DB
1026 BABA 6CCD780C 9564 5B8C656024DB

这里不要把交换后的字节串当作新的 UUID 文本展示给用户。数据库列保存的是 BINARY(16)；展示、日志和接口输出必须走配对的 BIN_TO_UUID(id, 1)。

把约定落到 BINARY(16) 主键

下面的表定义和插入语句就是可落地的最小模型。应用层生成 UUID 后只把字符串交给 SQL 函数，查询时在 SELECT 中还原，避免在业务代码里手动切片：

CREATE TABLE user_uuid (
  id BINARY(16) NOT NULL PRIMARY KEY,
  display_name VARCHAR(32) NOT NULL
);

INSERT INTO user_uuid (id, display_name) VALUES
  (UUID_TO_BIN('6ccd780c-baba-1026-9564-5b8c656024db', 1), 'alice'),
  (UUID_TO_BIN('6ccd780c-baba-1026-9564-5b8c656024dc', 1), 'bob');

SELECT display_name, HEX(id) AS stored_hex,
       BIN_TO_UUID(id, 1) AS decoded_uuid
FROM user_uuid
ORDER BY id;

这个查询同时验证了三件事：字段确实以 16 字节保存，主键可以参与排序，读取时使用同一个交换约定后文本值没有漂移。排序结果只能说明二进制排列可比较，不能直接承诺它就是业务创建时间排序；业务仍需要明确 UUID 版本和生成来源。

参数边界与迁移检查

迁移旧表时，先抽样比对原 CHAR(36) 值与新列的 BIN_TO_UUID(new_id, 1)。再检查所有写入入口、备份恢复脚本、报表 SQL 和日志格式是否使用同一个 flag。只改表结构、不改读取代码，通常会把问题推迟到接口返回时才暴露。

常见问题：UUID_TO_BIN 的几个误区

swap_flag=1 能让所有 UUID 都按时间有序吗

不能。MySQL 文档明确说明时间段交换假设使用 version 1 UUID；对不遵循该格式的 UUID，交换不会带来预期收益。

为什么错误 flag 得到的结果仍然像 UUID

BIN_TO_UUID 仍会按五组十六进制输出，所以格式可能完全正常；错误发生在字段分组顺序，必须和原字符串逐字比对，不能只看正则是否匹配。

应该在应用代码里手动交换字节吗

不建议。让 MySQL 的 UUID_TO_BIN 和 BIN_TO_UUID 负责转换，应用只维护“是否使用交换”的单一约定，更容易审计迁移、备份和跨服务读写。

上线前只保留一条约定

如果目标是紧凑存储，BINARY(16) 是字段选择；如果还要利用 version 1 UUID 的时间段布局，再统一使用 swap_flag=1。写入、读取、导入、导出四条链路必须一致。最后用固定 UUID 跑一次 HEX 和 round-trip 检查，确认值相同后再把约定推广到新表。