Symfony项目从旧版GUID（<=5.2）迁移至新版UUID组件（>=5.3）作为实体ID的可行迁移路径咨询

我刚好处理过类似的Symfony UUID迁移场景，给你几个不用折腾表复制或CSV导出的可行方案，一步步来就能搞定：

核心思路 #

问题根源是旧数据是char(36)格式的字符串UUID（带横杠），而新的Symfony Uid组件对应数据库的binary(16)格式（紧凑的二进制存储），直接改字段类型会导致数据损坏，必须先完成数据格式转换，再调整字段类型和实体映射。

方案一：数据库分步迁移+Doctrine适配（推荐） #

1. 先备份数据库！ #

这是所有操作的前提，别嫌麻烦，出问题能快速回滚。

2. 编写Doctrine迁移脚本，分步骤处理 #

步骤1：转换主表的UUID数据格式

针对你的用户表（假设表名为user），先把char(36)的UUID转换成二进制格式，以MySQL为例，执行SQL：

-- 先把带横杠的字符串UUID转成无横杠的十六进制，再转二进制
UPDATE user SET id = UNHEX(REPLACE(id, '-', ''));

如果是PostgreSQL，语法更简单：

UPDATE user SET id = id::uuid;

步骤2：修改主表的字段类型

把char(36)改成binary(16)：

ALTER TABLE user MODIFY COLUMN id BINARY(16) NOT NULL;

步骤3：处理关联表的外键

所有关联了user.id的外键字段（比如post.user_id），需要重复上面的两步：

-- 先转换外键字段的数据
UPDATE post SET user_id = UNHEX(REPLACE(user_id, '-', ''));
-- 再修改字段类型
ALTER TABLE post MODIFY COLUMN user_id BINARY(16) NOT NULL;

步骤4：恢复外键约束（如果之前禁用过）

如果你的外键约束在修改字段时报错，可以先临时禁用：

SET FOREIGN_KEY_CHECKS = 0;
-- 执行上面的字段修改操作后，再开启
SET FOREIGN_KEY_CHECKS = 1;

3. 确认实体映射的兼容性 #

你已经调整好的实体代码是没问题的：

use Symfony\Component\Uid\Uuid;

/**
 * @ORM\Id()
 * @ORM\Column(type="uuid", unique=true)
 */
private $id;

public function __construct()
{
    $this->id = Uuid::v4();
}

public function getId(): Uuid
{
    return $this->id;
}

Doctrine会自动把数据库的binary(16)字段映射成Uuid对象，查询时也可以用Uuid::fromString($oldStringUuid)来兼容旧的字符串查询需求。

方案二：双字段过渡（适合复杂关联场景） #

如果你的表关联特别多，一次性转换风险高，可以用双字段共存的方式：

• 在实体中新增一个uuidBin字段，类型为binary(16)，并添加映射：

  /**
   * @ORM\Column(type="uuid", nullable=true)
   */
  private $uuidBin;
  

• 编写迁移脚本，把旧的id字段值转换成二进制存入uuidBin
• 逐步修改所有关联关系，从使用id改为uuidBin
• 确认所有业务都切换到uuidBin后，删除旧的id字段，把uuidBin重命名为id，并设置为主键

关键注意事项 #

• 所有操作一定要在测试环境先验证，确保数据转换后可以正常读取（比如MySQL用HEX(id)查看转换后的二进制是否对应原UUID的无横杠字符串）
• 如果有自定义的Repository查询，原来用字符串UUID的地方要改成Uuid对象，比如：

  // 旧写法
  $user = $this->find('a1b2c3d4-5678-90ef-ghij-klmnopqrstuv');
  // 新写法
  $user = $this->find(Uuid::fromString('a1b2c3d4-5678-90ef-ghij-klmnopqrstuv'));
  

• 迁移后，新创建的实体ID会自动用Uuid::v4()生成，和旧数据的二进制格式兼容

内容的提问来源于stack exchange，提问作者ulfilas