MySQL ALTER TABLE 不支持事务回滚，即使在 START TRANSACTION 中执行成功后也无法 ROLLBACK；真正可回滚的只有 DML 操作，DDL 变更需依赖备份还原或迁移工具定义的降级逻辑。
MySQL ALTER TABLE 没有自动回滚机制
PHP 本身不提供数据库结构变更的事务回滚能力，ALTER TABLE 在 MySQL 中是 DDL 操作，默认会隐式提交当前事务，哪怕你包在 START TRANSACTION 里也没用。这意味着：一旦执行成功，就无法靠 ROLLBACK 撤销。
常见错误现象：START TRANSACTION; ALTER TABLE users ADD COLUMN phone VARCHAR(20); ROLLBACK; 执行完发现字段还在——不是 PHP 写错了，是 MySQL 就不支持。
- MySQL 8.0.23+ 对部分 DDL（如
ADD COLUMN）支持原子性，但不等于可回滚；它只是失败时自动清理，成功后依然不可逆 - PostgreSQL 的
ALTER TABLE可在事务中回滚，但 PHP 连接 PostgreSQL 时也得确认服务端版本和事务隔离行为 - 真正能靠事务兜底的，只有 DML（
INSERT/UPDATE/DELETE），不是 DDL
用 mysqldump + 临时表实现安全变更
最稳妥的“回滚”其实是提前备份 + 快速切换，而不是运行时撤销。核心思路：改结构前导出旧结构，变更失败或验证不通过时，用备份还原。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 变更前用
mysqldump --no-data --skip-triggers db_name table_name > backup_schema.sql备份表结构 - 若要保留数据并支持快速回切，可先
CREATE TABLE table_name_backup AS SELECT * FROM table_name;（注意：不复制索引、约束、默认值） - 更完整的方式是用
mysqldump --single-transaction --no-create-info db_name table_name > backup_data.sql配合结构备份 - PHP 中调用 shell 命令需严格过滤参数，避免注入；推荐用
escapeshellarg()包裹库名、表名
用 Laravel Migrations 或 Phinx 管理结构变更
手动写 ALTER TABLE 容易遗漏依赖或顺序，而迁移工具把“改什么”和“怎么退”写进代码，本质是人工定义回滚逻辑。
例如 Phinx 的 change() 方法要求你同时声明升级与降级动作：
public function change(Environment $env): void
{
$table = $this->table('users');
$table->addColumn('phone', 'string', ['limit' => 20])->save();
// 降级时自动执行：$table->removeColumn('phone')->save();
}关键点：
-
change()是语法糖，底层仍靠你写up()和down()；如果只写up()，rollback会报错 - 迁移文件名必须含时间戳（如
20240515123000_add_phone_to_users.php），否则顺序错乱导致回滚失败 - 生产环境执行前务必在测试库跑一遍
phinx rollback -t 1验证降级逻辑是否真能删字段/索引
误操作后紧急恢复的边界情况
没有万能回滚，只有分级响应。以下操作几乎无法干净还原：
-
DROP TABLE后未开启 binlog 或没定期备份？基本只能从最近全量备份恢复，期间数据丢失不可避免 -
ALTER TABLE ... MODIFY COLUMN改类型（如VARCHAR(10)→VARCHAR(5)）可能截断数据，且 MySQL 不记录原始长度，备份之外无补救 - 在高并发表上加索引（
ALTER TABLE ADD INDEX）卡住时，KILL进程只会中断操作，不会回退已写的临时文件，表可能处于“重建中”不可用状态
真正容易被忽略的是：很多团队以为开了 MySQL 的 binlog_format=ROW 就能闪回 DDL，其实 binlog 只记录最终结果（比如“某时刻表结构变成 X”），不记录中间步骤，没法生成反向 SQL。
