BIN_TO_UUID() 仅能正确还原由 UUID_TO_BIN() 生成的 BINARY(16) 值，要求字段类型为 BINARY(16)、MySQL ≥ 8.0.1，JOIN 条件须用二进制原值比对，应用层需统一标准化原始 UUID 格式。
BIN_TO_UUID() 函数必须搭配 UUID_TO_BIN() 一起用
BIN_TO_UUID() 不是万能解码器，它只负责把 BINARY(16) 类型的二进制值还原成标准 UUID 字符串（8-4-4-4-12 格式），前提是这个二进制值当初就是用 UUID_TO_BIN() 存进去的。如果你存的是 UNHEX(REPLACE(uuid_str, '-', '')) 或其他手写逻辑生成的二进制，BIN_TO_UUID() 很可能返回乱码或 NULL——因为字节序不一致。
常见错误现象：SELECT BIN_TO_UUID(id) FROM users 返回空字符串或报错 Invalid argument for function BIN_TO_UUID
- 确认字段
id类型是BINARY(16)，不是VARBINARY、CHAR或VARCHAR - 确认插入时用了
UUID_TO_BIN()，而不是自己拼UNHEX() - MySQL 版本必须 ≥ 8.0.1；5.7 及更早版本不支持该函数
JOIN 场景下 BIN_TO_UUID() 只能用于 SELECT，不能用于 ON 条件
想在关联时“把二进制转成字符串再比对”？别这么干。例如：ON BIN_TO_UUID(o.user_uuid) = BIN_TO_UUID(u.id) 会强制全表扫描，索引彻底失效，性能雪崩。
正确做法是：所有 JOIN 条件必须保持二进制原样比对，BIN_TO_UUID() 只出现在 SELECT 列表里用于展示。
- 建表时确保关联字段类型一致：
orders.user_uuid BINARY(16)和users.id BINARY(16) - JOIN 写法必须是：
ON o.user_uuid = u.id，不是字符串转换后比对 - 需要显示可读 UUID 时才加：
SELECT BIN_TO_UUID(u.id) AS user_uuid_str, ...
大小写和横线格式必须在应用层统一，数据库不负责容错
BIN_TO_UUID() 输出永远是小写 + 横线格式（如 a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11），但它不关心输入来源。真正危险的是：应用层传入的原始 UUID 字符串格式不一致。
比如 A 服务传 a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11，B 服务传 A0EEBC999C0B4EF8BB6D6BB9BD380A11（大写无横线），两者经 UUID_TO_BIN() 后生成的二进制完全不同，JOIN 结果要么为空，要么重复匹配。
- 数据库层不做标准化处理，
UUID_TO_BIN()对大小写敏感 - 必须在应用代码中统一 normalize：转小写、补横线、校验长度和格式
- 建议在 INSERT 前加一层校验，避免脏数据入库
SELECT 中使用 BIN_TO_UUID() 时注意隐式类型转换陷阱
如果字段定义为 BINARY(16)，但你在 WHERE 或 ORDER BY 中误写了字符串条件，MySQL 会尝试隐式转换，导致索引失效或结果偏差。例如：WHERE id = 'a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11' 看似合理，实际触发全表扫描。
- 查二进制字段必须用二进制值：
WHERE id = UUID_TO_BIN('a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11') - 排序也应基于二进制：
ORDER BY id，而非ORDER BY BIN_TO_UUID(id)（后者无法利用索引） - 如果业务强依赖字符串排序，说明设计有缺陷——UUID 本身就不适合做有序主键
真正容易被忽略的不是函数怎么调，而是谁在什么时候、以什么格式把原始字符串塞进 UUID_TO_BIN() —— 这一步出错，后面所有 BIN_TO_UUID() 的输出都不可信。
