database-migration - Liquibase 数据库迁移，随着时间的推移进行管理

Question

我们一直在使用 Liquibase 进行数据库迁移，它运行在 Migrations.xml 文件之上。这引用了我们所有的迁移，因此它看起来具有以下效果:

<include file="ABC.xml" relativeToChangelogFile="true" />
<include file="DEF.xml" relativeToChangelogFile="true" />
<include file="HIJ.xml" relativeToChangelogFile="true" />
...

但是，随着时间的推移，这个长度变得非常长。寻求重构有人解决了这个问题吗？有哪些选项可以从根本上浓缩所有这些 future ？

谢谢

Answer 1

没有单一的答案，什么最有效取决于您的环境、流程以及您为什么要削减它们。

一般来说，我建议让您的变更日志增长，因为现有步骤是您已经测试、部署并知道是正确的步骤。改变它们会带来风险，但最好避免这种风险。保持变更日志不变还允许您继续像旧实例一样引导新的开发/QA 数据库。

虽然拥有较大的变更日志会带来一些性能损失，但 Liquibase 试图将其保持在最低限度，并且主要只是解析变更日志文件，然后从 DATABASECHANGELOG 表中读取，该表应该可以很好地扩展。由于 liquibase update 通常很少运行，因此即使需要几秒钟的时间来运行，通常也没什么大不了的。

话虽如此，有时清除您的变更日志是有意义的。最好的方法取决于您要解决的问题是什么。

最简单的方法通常是删除对最旧的变更日志文件的引用。如果您知道所有数据库都已应用 ABC.xml 和 DEF.xml 中的更改集，您只需从主更改日志中删除对它们的引用，一切都会好起来的。 Liquibase 不关心 DATABASECHANGELOG 表中是否存在“未知”变更集。如果您想继续使用 ABC.xml 和 DEF.xml 增强开发和 QA 环境，您可以创建第二个旧版“主变更日志.xml，其中包含它们，并在需要时运行两个变更日志，或者确保旧版变更日志同时包含旧的变更日志”。和新的变更日志。

如果您不想完全删除changeLog引用，可以手动修改现有的changeSet。通常，只需进行一些更改即可对更新性能产生很大影响。例如，如果创建了索引然后删除了索引，您可以通过删除删除并创建变更集来跳过创建成本。同样，liquibase 不关心已经运行变更集的数据库，也不会看到它们的新变更集。如果您的某些数据库可能仍具有索引并且希望将其删除，则可以在删除创建变更集后对删除变更集使用 indexExists 前提条件。

前提条件检查也可能很昂贵，特别是取决于数据库供应商。有时删除现在不需要的前提条件检查也可以提高性能。