Symfony4怎么在不锁表的情况下完成大表模型迁移-php教程-PHP中文网

在 symfony 4 中对大表迁移需最小化锁时长，优先用 gh-ost/pt-online-schema-change（mysql）或 concurrently（postgresql），拆分高危操作为多阶段执行，禁用自动生成的 drop/rename，数据填充交由后台任务，并上线前实测锁表现与执行时间。

symfony4怎么在不锁表的情况下完成大表模型迁移

在 Symfony 4 中对大表执行模型迁移时，避免锁表是保障线上服务可用性的关键。Doctrine Migrations 默认生成的 SQL（如 ALTER TABLE）在 MySQL 5.6+ 或 PostgreSQL 中可能触发全表重建或长时间写锁，尤其在千万级数据表上极易导致请求超时、主从延迟甚至服务中断。真正可行的方案不是“完全不锁”，而是**最小化锁时长、分阶段变更、绕过 DDL 阻塞**。

用在线 DDL 工具替代原生 ALTER

Doctrine 本身不提供在线 DDL 能力，需借助数据库层工具：

MySQL 场景：优先使用 pt-online-schema-change（Percona Toolkit）或 gh-ost。它们通过影子表+触发器+逐行拷贝实现无锁变更。例如添加字段：
gh-ost --user=root --password=xxx --host=localhost --database=mydb --table=orders --alter="ADD COLUMN status VARCHAR(20) DEFAULT 'pending'" --allow-on-master --cut-over=default --exact-rowcount --concurrent-rowcount --default-retries=120 --panic-flag-file=/tmp/ghost.panic.flag --execute
PostgreSQL 场景：多数 ALTER TABLE ... ADD COLUMN 操作本身不锁表（只要不涉及 NOT NULL + 默认值），但加索引需用 CONCURRENTLY：
CREATE INDEX CONCURRENTLY idx_orders_user_id ON orders (user_id);
注意：CONCURRENTLY 不能在事务块中执行，且建索引期间允许 DML，但失败时不回滚，需手动清理。

拆分迁移逻辑，避开高危操作

Doctrine 自动生成的迁移常含危险语句，应主动规避：

Symfony Windows版

Symfony Windows版用于下载 Symfony CLI 5.17.1 官方安装包，辅助开发者创建 Symfony 项目并进入框架学习与配置流程。

下载

禁用自动生成的 DROP COLUMN、RENAME TABLE、MODIFY COLUMN —— 这些在 MySQL 中基本无法在线执行；
将“加字段+填默认值”拆为两步：
第一步：仅 ADD COLUMN status VARCHAR(20)（允许 NULL）；
第二步：后台任务分批 UPDATE orders SET status = 'pending' WHERE status IS NULL LIMIT 10000；
第三步：再执行 ALTER TABLE orders ALTER COLUMN status SET NOT NULL（此时数据已补全）；
不要在 up() 中写循环更新百万行的 PHP 代码 —— 迁移应只做结构变更，数据填充交给独立命令或异步 job。

用 Doctrine 扩展支持安全迁移

引入 doctrine/doctrine-migrations-bundle 以外的辅助能力：

安装 spatie/laravel-schemaless-attributes 类似思路的轻量方案（虽为 Laravel 设计，但其“动态字段存 JSON”思想可借鉴），把高频变更字段转为 JSON 字段，避免频繁 ALTER；
使用 doctrine/dbal 的 SchemaManager 手动构造低风险变更，例如：
$schema->getTable('orders')->addColumn('status', 'string', ['notnull' => false, 'length' => 20]);
确保生成的是最简 ADD COLUMN，而非带默认值的复杂语句；
对必须的重命名操作，采用“新建字段 → 同步写 → 切换读 → 清理旧字段”三阶段策略，全程无 DDL 锁。