UUID()返回标准v1格式字符串（36字符，如'f4185127-950e-11ef-8c26-00155d012345'），是VARCHAR(36)类型，含时间戳、MAC地址等，非纯随机，不可直接存BINARY(16)，需UNHEX(REPLACE())转换。
MySQL 里 UUID() 函数到底返回什么格式
UUID() 返回的是标准 UUID v1 格式字符串，共 36 个字符，形如 'f4185127-950e-11ef-8c26-00155d012345'。它由时间戳、MAC 地址（或随机 fallback）、序列号拼接而成，不是纯随机，也不带版本校验位。
注意：这个值是字符串类型（VARCHAR(36)），不是二进制或整数。直接存进 BINARY(16) 字段会报错或截断，必须用 UNHEX(REPLACE(UUID(), '-', '')) 转换。
- 默认不带引号，但 SQL 中插入时需加单引号（因为是字符串）
- 每调用一次生成一个新值，即使在同一语句中多次出现也互不相同
- 不能在普通索引列上直接用作主键——长度大、无序，会导致 B+ 树频繁分裂
用 UUID() 当主键？先看这三件事
很多人想用 UUID() 替代自增 ID 避免暴露业务量或做分库分表，但实际落地要权衡清楚：
- 存储开销翻倍：
VARCHAR(36)比BIGINT多占约 4 倍空间；若转成BINARY(16)，虽节省空间，但写入性能下降明显（InnoDB 页分裂更频繁） - 索引效率低：UUID 无序，新记录大概率插入到中间页而非末尾，导致大量 page split 和 buffer pool 刷脏压力
- 无法利用范围查询优势：比如查“今天注册的用户”，
id > 'xxx'这类操作对 UUID 完全失效
如果真要用，建议配合 UUID_TO_BIN()（MySQL 8.0.1+）和 BIN_TO_UUID()，并把字段定义为 BINARY(16) PRIMARY KEY，再加 STORED 虚拟列用于可读性展示。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
UUID_SHORT() 是不是更合适？别被名字骗了
UUID_SHORT() 不是 UUID，也不是 GUID，而是 MySQL 自研的一个 64 位整数，格式为：server_id 。它依赖 server_id 和系统时间，且要求 <code>auto_increment_increment 和 auto_increment_offset 设置得当。
- 只在单机环境绝对安全；多主复制下极易冲突（server_id 冲突或时间回拨）
- 数值递增，适合做主键，但暴露服务器 ID 和大致上线时间，有信息泄露风险
- 最大值约 2^64，远高于业务常见量级，但一旦溢出就崩溃，无法自动回绕
它和 UUID() 完全是两类东西：一个靠拼凑字符串防冲突，一个靠整数规则保顺序——别因为名字里都有 “UUID” 就混用。
生成后怎么存、怎么查才不踩坑
存的时候不处理格式，查的时候就容易出错。常见问题包括大小写比较失败、带/不带横杠匹配不上、PHP/Java 客户端解析异常。
- 统一用小写存储：
LOWER(UUID())，避免大小写敏感 collation 导致的索引失效 - 去横杠再存二进制：
UNHEX(REPLACE(UUID(), '-', ''))，查的时候用BIN_TO_UUID()或手动拼回字符串 - WHERE 条件里别写
id = 'F418...'（大写），而要用id = LOWER('F418...')或确保输入已标准化 - 应用层生成 UUID（如 PHP 的
ramsey/uuid）再传入 MySQL，比依赖数据库函数更容易控制版本和格式
最麻烦的其实是跨语言一致性：MySQL 的 UUID() 是 v1，而很多客户端默认生成 v4，时间戳部分不一致，联合调试时容易误判是不是同一个 ID。
