UUID (通用唯一标识符）是数据库中使用的 128 位值，除其他外，用于唯一标识表条目。它们表示为十六进制字符串，分为由连字符分隔的五组（示例: 09fe49b3-4d2b-471c-ac04-36c9e706b85f）。 有 很多的 讨论 关于 UUID 在数据库中的优缺点——它们在分布式系统中是不可或缺的。
因此，在微服务和多租户应用程序中，值得考虑引入 UUID。 在 PHP 框架Laravel中从数据类型 BigInteger 切换到 UUID（ RFC 4122规范中 UUID 版本 4 的可排序变体）很快完成：首先，我们创建一个新特征:
2aa7136d977617159be1834eaf40e871
然后我们添加我们所有的模型:
2aa7136d977617159be1834eaf40e871
在 Laravel 9⁺ 中这更容易：在这里我们已经准备好使用HasUuids特征。 或者，该框架还提供对相关但仍然相当未知的数据类型ULID的支持，由于更好的可读性和可排序性，这可能会很有趣。
困难的部分是现有数据的迁移。 大致可以如下进行:
- 向所有表添加新的具有空值的 UUID 列
（每个都基于所有主键和外键列） - 将 UUID 值写入新列
（采用升序主键和更新后的外键） - 删除原始列
- 重命名新列
这里有几个挑战：迁移过程需要很长时间，并且新列会附加到表的末尾（可能的解决方案： 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