MySQL不建议使用UUID作为主键的原因

### 在 MySQL 中同时使用 UUID 和 自增主键的方法 #### 方法概述 为了充分利用两种主键的优势，在实际应用中可以选择创建两个字段分别用于存储自增 ID 和 UUID。通常情况下，自增 ID 被设为主键并负责唯一标识记录；而 UUID 则作为一个辅助列存在，主要用于跨系统识别或分布式环境下的数据同步。 #### 实现方式 可以通过定义复合主键的方式来实现这一目标： ```sql CREATE TABLE example_table ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, uuid CHAR(36) NOT NULL DEFAULT (UUID()), name VARCHAR(255), PRIMARY KEY (id), -- 设置自增ID为主键 UNIQUE INDEX idx_uuid(uuid)-- 添加唯一索引到UUID上以确保其唯一性 ); ``` 上述 SQL 语句展示了如何在一个表内同时维护 `id`（自增整数型）和 `uuid` 字段，并通过设置合适的约束条件来保障两者的特性和功能[^1]。 #### 注意事项 当采用这种方式时需要注意以下几点： - **性能影响**：虽然引入了额外的 UUID 字段，但由于查询操作主要依赖于效率更高的自增主键，因此整体性能不会受到太大负面影响。 - **空间占用**：相比单纯的自增主键方案，此方法确实增加了每条记录所需存储的空间量，因为需要保存较长字符串形式的 UUID 值。 - **插入顺序问题**：由于自增主键能够保证新纪录总是追加到最后位置，这有助于提高写入速度；而对于随机生成的 UUID，则可能引起页分裂等问题从而降低性能[^2]. #### 优点对比 | 特征 | 自增主键 | UUID | | --- | --- | --- | | 数据长度 | 较短 | 较长 | | 插入性能 | 更高 | 可能较低 | | 分布式支持 | 不友好 | 支持 | 综上所述，在某些特定场景下，比如涉及到多数据库实例间的数据交换或是希望获得全局唯一的实体标识符的情况下，可以考虑这种混合模式的设计思路[^3]。