数据库中的 UUID10
22

UUID (通用唯一标识符) 是在数据库中使用的 128 位值，除其他外，用于唯一标识表条目。 它们表示为一个十六进制字符串，分为由连字符分隔的五组（示例: 09fe49b3-4d2b-471c-ac04-36c9e706b85f）。 有 很多的 讨论 关于 UUID 在数据库中的优缺点——它们在分布式系统中是不可或缺的。

---

因此，在微服务和多租户应用程序中，值得考虑引入 UUID。 在 PHP 框架Laravel中从数据类型 BigInteger 切换到 UUID（ RFC 4122规范中 UUID 版本 4 的可排序变体）很快完成：首先，我们创建一个新特征:

2aa7136d977617159be1834eaf40e871

然后我们添加我们所有的模型:

2aa7136d977617159be1834eaf40e871

在 Laravel 9⁺ 中这更容易：在这里我们已经准备好使用HasUuids特征。 或者，该框架还提供对相关但仍然相当未知的数据类型ULID的支持，由于更好的可读性和可排序性，这可能会很有趣。

困难的部分是现有数据的迁移。 大致可以如下进行:

1. 向所有表添加新的具有空值的 UUID 列
   （每个都基于所有主键和外键列）
2. 将 UUID 值写入新列
   （使用升序主键加上更新的外键）
3. 删除原始列
4. 重命名新列

这里有几个挑战：迁移过程需要很长时间，并且新列会附加到表的末尾（可能的解决方案： resort columns ）。 一种更直接的方法是直接转换列。

如果你把那个 PostgreSQL 第一，您可以（当然，在之前的备份之后）运行以下查询，例如（在此之前，您可以删除您在 Z 中排除的所有表。 19/31 替换，以及Z中自己的特殊规则。 37/39 add) 并复制从它生成的所有查询:

2aa7136d977617159be1834eaf40e871

如果您现在一起运行生成的查询，那么您已经在很短的时间内迁移了数据库。 虽然由此生成的 UUID 不符合 v4 规范，但它们在字典上与先前条目的顺序相同，不会与新的 UUID 冲突（在 v4 的第 3 组中总是有一个 4, 在迁移的变体中总是一个 0)，这也意味着新的 UUID 总是大于迁移的 UUID。

之后建议删除所有 Laravel 缓存（php artisan cache:clear && php artisan route:clear && php artisan config:clear && php artisan view:clear && composer dump-autoload && rm -rf bootstrap/cache/*/*) 和运行会话 (rm -f storage/framework/sessions/*） 清空。 当然，整个事情也可以在 Laravel 迁移中实现:

2aa7136d977617159be1834eaf40e871

转换后，在未来的迁移中使用 bigIncrements 或者。 bigInteger 然后 uuid:

2aa7136d977617159be1834eaf40e871