uuid v4 不适合直接作为数据库聚簇索引主键，因其完全随机性导致innodb频繁页分裂、索引碎片化；须配合二进制存储（如mysql用uuid_to_bin(..., 1)启用swapflag）和引擎适配才能缓解性能问题。
uuid4 本身并不“更适合”做数据库主键——它只是在特定场景下可选，但默认用 uuid4 反而是最容易踩坑的起点。是否适合，取决于你用在哪、怎么存、有没有配套优化。
UUID v4 的生成行为决定了它不适合直接当聚簇索引
uuid4 是完全随机生成的 128 位值，高位无时间信息、无顺序性。InnoDB 的聚簇索引要求主键尽量有序，否则：
- 每次插入都可能落在 B+ 树任意位置，触发频繁页分裂
- 索引页填充率从 94% 降到约 50%，浪费磁盘和内存
- 大量碎片导致后续查询需要更多 I/O
这跟数据库引擎强相关，不是 Python 层能绕开的问题。PostgreSQL 对 uuid 类型做了深度优化，MySQL 则必须手动处理存储格式才能缓解。
Python 中 default=uuid.uuid4 和 default=uuid.uuid4() 的区别很致命
Django 或 SQLAlchemy 中设主键时，常见错误是写成：default=uuid.uuid4()这会在模块加载时就执行一次，所有记录共享同一个 ID。正确写法是：
default=uuid.uuid4（不带括号，传函数对象本身）
-
uuid.uuid4：每次新建模型实例时调用，生成新值 -
uuid.uuid4()：仅在迁移文件生成或模块导入时执行一次，变成静态默认值
如果已有数据表再加 UUIDField 主键，Django 会报 NOT NULL constraint failed —— 因为它无法给历史行自动填唯一值，必须显式提供 default 或用 RunPython 手动补全。
MySQL 中用 uuid4 必须配合 bin 存储 + swapflag
直接存字符串（VARCHAR(36)）是灾难性的：
- 占用 36 字节，比 BINARY(16) 多 125% 存储空间
- 字符串比较慢，索引体积大，缓存命中率低
必须用：
UUID_TO_BIN(UUID(), 1)其中第二个参数
1 表示启用 swapflag，把时间戳段移到高位，让二进制表示具备一定局部顺序性（虽不如 v7，但比裸 v4 好得多）。
- 不加
swapflag：随机性原样保留，索引效率几乎没改善 - 加了之后：相同毫秒内生成的 UUID 在二进制层面更接近，减少页分裂
PostgreSQL 用户反而轻松些：uuid 类型原生支持，uuid_generate_v4() 直接可用，但也要注意：v4 仍是随机的，高并发写入压力下仍比 v1/v7 差。
真正容易被忽略的点不是“怎么生成”，而是“怎么存”和“用在哪”。一个 uuid4() 调用本身没问题，但它一旦落到 MySQL 的 VARCHAR 主键上，性能衰减就从第一万条记录开始变得明显。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
