row_number()是窗口排序函数，仅在查询时按order by生成临时序号，不持久、不全局唯一；uuid是128位全局唯一标识，适合跨库/离线场景，但插入性能低于自增id。
没有“更好”，只有“更合适”——ROW_NUMBER() 适合单次查询内行序控制，UUID 适合需要全局唯一、跨表/跨库/离线生成的场景。两者根本不是同一类工具。
ROW_NUMBER() 不是 ID 生成器，而是窗口排序函数
它只在当前查询执行时按指定 ORDER BY 逻辑生成临时序号，不持久、不唯一（换一次 ORDER BY 就全变）、不保证分布均匀。
- 常见错误：用
ROW_NUMBER() OVER (ORDER BY RAND())模拟自增，结果数据严重倾斜——因为RAND()导致 shuffle 全局重排，小表没事，大表 Shuffle 成瓶颈 - 正确用法：分页（
ROW_NUMBER() OVER (ORDER BY create_time DESC)）、去重取最新（QUALIFY ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY ts DESC) = 1） - 性能影响：依赖排序字段是否走索引；若
ORDER BY字段无索引，会触发全表排序 + 临时磁盘文件，IO 开销陡增
UUID 是真正意义上的唯一标识生成机制
它不依赖数据内容或顺序，每次调用都独立产出一个 128 位值（通常转为 32 位十六进制字符串或 BINARY(16) 存储）。
- MySQL 中直接用
UUID()函数，返回格式如'550e8400-e29b-41d4-a716-446655440000'；PostgreSQL 用gen_random_uuid()（需启用pgcrypto） - 别存成
VARCHAR(36)：索引体积暴涨，查询变慢；必须用BINARY(16)+UUID_TO_BIN()写入，BIN_TO_UUID()读出 - v4 随机 UUID 插入性能比自增低 30%~100%，主因是 B+ 树页分裂率高；v7（带毫秒时间戳前缀）可缓解，但 MySQL 8.0.31+ 才原生支持
真正要选“ID 生成方案”时，别只盯 ROW_NUMBER 和 UUID
它们连同级竞争者都不是：前者是 SQL 计算函数，后者是标识符格式。实际选型要看存储引擎和写入模式。
- 单库单表、QPS BIGINT AUTO_INCREMENT，最稳
- 分库分表、微服务、要隐藏增长量 → 优先考虑
Snowflake或MySQL 8.0 的 UUID v7，而非原始 UUID - Hive/Spark 等离线数仓 →
UUID()或reflect("java.util.UUID", "randomUUID")可行，但注意row_number()在 reduce 阶段易 OOM - 如果只是导出报表要加个“序号列”，就老实用
ROW_NUMBER()，别硬套 UUID —— 多占空间、无业务意义、还拖慢导出
最容易被忽略的一点：UUID 的“唯一性”只在生成端成立。如果你把两个不同集群导出的 UUID 数据合并进一张表，又没做去重校验，照样可能撞——因为 v4 是概率唯一，不是数学唯一。真要 100% 避免冲突，得靠业务层加约束或用中心化发号器。
