为什么不在更新脚本中累积对开发模式的更改，并在下一个版本中运行该脚本呢？
确实有不同的模式比较工具，但是，在我看来，它们应该只用于检查更新脚本是否正确，而不是生成脚本。
在发布时，您应该将生成新模式的脚本和更新脚本作为空脚本提交给版本控制系统。
假设您的模式如下：

-- schema.sql
CREATE TABLE t1 (
  `t_id` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  `t_data` VARCHAR(45) NOT NULL,
  PRIMARY KEY (`t_id`)
) ENGINE = InnoDB COLLATE utf8_feneral_ci;

承诺1
现在，您的表中有大量数据处于生产状态，其中有大量重复数据，您希望进行一些规范化：

• 将非重复数据放入单独的表中
• 使用t1表中的参考：

脚本：

-- updates.sql
CREATE TABLE t2 (
  `d_hash` CHAR(32) NOT NULL COLLATE ascii_general_ci,
  `t_data`  VARCHAR(45) NOT NULL,
  PRIMARY KEY (`d_hash`)
) ENGINE = InnoDB COLLATE utf8_general_ci;

ALTER TABLE t1
  ADD COLUMN `d_hash` CHAR(32)COLLATE ascii_general_ci AFTER `t_data`;

UPDATE t1 SET d_hash = MD5(UPPER(t_data));

INSERT IGNORE INTO t2 (t_data, d_hash)
SELECT t_data, d_hash
FROM t1;

ALTER TABLE t1 DROP COLUMN `t_data`,
MODIFY COLUMN `d_hash` CHAR(32) COLLATE ascii_general_ci NOT NULL,
ADD CONSTRAINT `FK_d_hash` FOREIGN KEY `FK_d_hash` (`d_hash`)
REFERENCES `t2` (`d_hash`) ON DELETE CASCADE ON UPDATE CASCADE;

承诺2
放行

-- schema.sql
CREATE TABLE  t1 (
  `t_id` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  `d_hash` CHAR(32) COLLATE ascii_general_ci NOT NULL,
  PRIMARY KEY (`t_id`),
  KEY `FK_d_hash` (`d_hash`),
  CONSTRAINT `FK_d_hash` FOREIGN KEY (`d_hash`)
  REFERENCES `t2` (`d_hash`)
    ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB COLLATE utf8_general_ci;

-- updates.sql
-- Empty

承诺3
我想看看一个比较工具，将允许您这样做简单得多。

我认为一个好的方法是像修改代码一样修改数据库，将它们放在源代码控制中，并使部署良好且可重复。
我对这类事情的哲学就像DevOpsWire上的这个模式：https://web.archive.org/web/20111025093215/http://devopswire.com/patterns/database-changes-as-code
工具方面，看看DB-Deploy和Liquibase之类的工具。

在Need a better way to manage database schema changesCompare two MySQL databases上定义的相同方法将完美地工作。
您也可以查看比较相关的帖子here。
此外，最好是维护您在准备或预部署时可能做出的更改脚本，并在迁移到生产环境时一次性执行它们。

尝试字节库（bytebase.com）
它是基于网络和开源的。
对于你的问题，
方法1：创建dev-prod管道。方法2：执行模式同步。
你甚至可以做GitOps工作流，这意味着你把sql脚本提交到GitHub/GitLab，然后提交会自动触发脚本执行，然后写回LATEST sql来记录快照。