symfony 2 中无官方“数据库查询数据迁移工具”，需分两步实现：一、用 doctrine:migrations:diff 同步结构，先反向生成实体再生成迁移文件；二、将旧查询逻辑重构为 doctrine repository/dql/querybuilder 模式，并处理视图、enum 等特殊场景，最后验证与备份上线。
Symfony 2 中没有官方叫“数据库查询数据迁移工具”的组件，所谓“从旧系统迁移查询逻辑”，本质不是迁移 SQL 或查询语句本身，而是把旧系统的数据读取方式（比如原生 SQL、自定义 DAO、老框架的 ORM 调用）重构为 Doctrine ORM 的标准模式，并通过 Doctrine Migrations 管理结构变更。整个过程分两块：结构迁移（表、字段）和查询逻辑迁移（代码层）。下面讲清楚怎么做。
一、先同步数据库结构：用 doctrine:migrations:diff 生成迁移文件
这是所有后续查询迁移的前提——新库结构必须和旧系统一致，或按新设计演进。
- 确保旧系统数据库已连到 Symfony 2 项目（配置 config.yml 中的
doctrine.dbal） - 若旧库已有表，运行命令让 Doctrine 反向生成实体映射：
php app/console doctrine:mapping:import --force AcmeStoreBundle annotation
（会生成带@ORM\Column注解的 Entity 类） - 检查每个实体类是否完整：必须有
@ORM\Entity、@ORM\Table，新增字段要有@ORM\Column，否则doctrine:migrations:diff会忽略 - 执行：
php app/console doctrine:migrations:diff
生成类似Version20260601153000.php的迁移文件，它会把当前实体与数据库的差异转成up()中的CREATE TABLE或ALTER TABLE
二、把旧查询逻辑改写成 Doctrine 标准调用
旧系统常见查询方式（如直接拼 SQL、mysql_query、手写 DAO）要逐步替换成 Repository + DQL/QueryBuilder 模式，才能享受缓存、关联、生命周期等 ORM 优势。
- 查单条记录，不用
SELECT * FROM user WHERE id = ?：
改用$em->getRepository(User::class)->find($id) - 条件查询，避免字符串拼接：
改用$repo->findOneBy(['status' => 'active', 'type' => 'vip'])或$repo->findBy(['deleted' => false], ['createdAt' => 'DESC']) - 复杂查询（含 JOIN、聚合、子查询）用 DQL：
$dql = 'SELECT u FROM AcmeStoreBundle:User u JOIN u.profile p WHERE p.city = :city';$users = $em->createQuery($dql)->setParameter('city', 'Beijing')->getResult(); - 动态条件用 QueryBuilder：
$qb = $repo->createQueryBuilder('u');<br>if ($minAge) { $qb->andWhere('u.age >= :age')->setParameter('age', $minAge); }
三、处理特殊旧逻辑：视图、存储过程、非标准字段
Doctrine 默认不管理视图或 SP，但可兼容使用；非标准类型（如 MySQL 的 ENUM、SET）需手动映射。
- 如果旧系统依赖数据库视图，可在 Entity 上用
@ORM\Table(name="user_summary_view")，并设@ORM\Entity(readOnly=true)防止误写 - ENUM 字段在 Symfony 2 中需自定义类型（实现
Doctrine\DBAL\Types\Type），并在doctrine.dbal.types中注册，否则diff会报错或跳过 - 时间戳字段（如
created_at）建议用@ORM\Column(type="datetime")+ 生命周期回调，替代旧系统中手动赋值 - 避免在迁移中用
$this->addSql()写原生语句——除非万不得已（如加全文索引、修改 collation），否则破坏可移植性
四、验证与上线前关键检查
迁移不是执行完就结束，尤其涉及查询逻辑替换时，容易漏掉边界情况。
- 执行前跑状态检查：
php app/console doctrine:migrations:status，确认新迁移在 “Available” 列表且未执行 - 在开发环境完整走一遍旧业务流程，对比 SQL 日志（开启
doctrine.dbal.logging: true）看查询是否等价、性能有无退化 - 生产环境执行迁移前，务必备份数据库；迁移命令加
--no-interaction和--allow-no-migration（防空执行） - 回滚方案必须提前写好：
down()方法不能留空，哪怕只是$schema->dropTable('legacy_log')—— Doctrine 不会自动反推
