UUID适合作为主键因其全局唯一性、无需中心协调、支持客户端预生成；但需按数据库优化存储（如MySQL用BINARY(16)）、避免随机UUID损害聚簇索引性能，并优先考虑有序变种。
直接用 UUID 作为数据库主键是可行的，但需结合具体数据库类型、性能要求和业务场景来设计，不能简单替换自增 ID。
为什么 UUID 适合作为主键？
UUID（如 v4 版本）由时间戳、随机数、MAC 地址等组合生成，在分布式系统中能保证全局唯一，无需中心协调。它天然规避了分库分表时的主键冲突问题，也方便客户端在插入前就生成 ID（例如前端上传文件时预生成记录 ID）。
不同数据库的推荐用法
PostgreSQL：推荐使用 UUID 类型 + gen_random_uuid()（需启用 pgcrypto 扩展）或应用层生成。索引效率接近整型，且支持排序（v1/v2 有时间序特性）。
MySQL：避免用 CHAR(36) 存储标准格式 UUID（如 550e8400-e29b-41d4-a716-446655440000），建议转为 BINARY(16) 存储（去掉连字符并 hex 解码），可提升索引空间利用率与查询速度。
SQL Server：可用 UNIQUEIDENTIFIER 类型，配合 NEWID()（随机）或 NEWSEQUENTIALID()（有序，减少页分裂）。
关键注意事项
• 索引性能影响：UUID 比 64 位整型更大，B+ 树索引深度增加，写入时更易引起页分裂（尤其 MySQL 默认随机 UUID）。若主键还被用作外键或频繁 JOIN，开销更明显。
• 不建议直接用于聚簇索引（如 MySQL InnoDB 默认主键即聚簇索引）：随机 UUID 导致数据物理存储无序，降低范围查询和顺序插入性能。可考虑：主键用 UUID，另建一个自增列做聚簇索引（需禁用主键聚簇）；或改用有序 UUID（如 ULID、KSUID 或 UUID v1）。
• 查询可读性与调试成本上升：相比 12345，f47ac10b-58cc-4372-a567-0e02b2c3d479 更难记忆和口头沟通，日志、URL、API 返回中需权衡是否暴露原始 UUID。
实用建议
• 新项目且明确需要分布式 ID 时，优先评估 有序 UUID 变种（如 PostgreSQL 的 pg_ulid、Go 的 ulid 库），兼顾唯一性与时间局部性。
• 若已用自增 ID 且无分片需求，不必强行切换——UUID 不是银弹，只为解决特定问题而存在。
• 在应用层生成时，统一使用标准库（如 Python 的 uuid.uuid4()、Java 的 UUID.randomUUID()），避免自行拼接出错。
• 对高频写入表，可考虑“UUID 主键 + 自增辅助列用于排序/分页”，而非让 UUID 承担所有角色。
