我正在使用MySQL DB构建一个用于关系存储的应用程序。该应用程序旨在用于持续交付，为此，应用程序DB必须就地升级。
1。 Application -> Transactional Statements -> DB -> Table View (Schema Version) -> Table
单个数据库用于所有应用程序版本。最新的模式版本定义了真实的表结构，通过模拟先前模式的表视图支持以前的模式版本。
2。 Application -> Transactional Statements -> DB (Schema Version) -> Table
发布新架构时，会复制数据库并将架构更改应用于新数据库。跟踪启动过程后旧数据库上的事务并将其应用于新数据库。
升级完成后（并且所有应用程序部署都已切换到新架构），旧数据库将被转储。
选项2在技术上很简单，因为不需要修改活动数据库的模式。但是，如果DB增长到相当大的规模，那么资源消耗将变得很大;因此，这种方法可以支持的应用程序大小存在实际限制。
因此，选项1是首选，但它提出了应用事务性DDL语句的问题。
如何修改数据库表和相应的表视图，而不会有数据损坏或应用程序访问数据库的能力中断的风险？
我目前的想法是如下所示：
- 应用创作和补充
- 创建新表
- 创建新列
- 应用列重命名
- 锁定表格视图（以及扩展名，基础表格）
- 重命名列
- 修改表视图以使用新的目标列名称
- 解锁表格视图
- 应用表格重命名
- 锁定表格视图（以及扩展名，基础表格）
- 重命名基表
- 修改表视图以使用新的基表名称
- 解锁表格视图
从那里，将创建新的模式表视图，以便在部署下一个模式更改时可以使用相同的策略。
注意：任何已删除的列或表都将在转换期间保留，但会重命名为追加_deprecate或其他一些识别后缀
据我所知，MySQL中的事务性DDL语句不可能，因为语句将触发隐式提交。 这是正确的吗？
上面描述的选项1方法是否有效？
具体来说，我有两个问题：
表锁会导致应用程序中断。此处唯一关注的是单个表锁持续如此之久以至于等待连接超时？如果是这样，通过在应用程序暂存期间测试每个表锁的持续时间，这应该是可管理的。
回滚我显然没有这种安排的自动回滚功能。但是，我需要的是通过更改表视图来镜像对基表的任何修改。 是否可以在单个事务中对基表和表视图应用更改？如果没有，我将只需要在部署架构更改之前进行非常彻底的测试。