我们一直在使用 Liquibase 进行数据库迁移，它使用 Migrations.xml 文件运行。这引用了我们所有的迁移，所以看起来有点像：
<include file="ABC.xml" relativeToChangelogFile="true" />
<include file="DEF.xml" relativeToChangelogFile="true" />
<include file="HIJ.xml" relativeToChangelogFile="true" />
...
但是，随着时间的推移，这已经变得非常长。想要重构这个有没有人解决这个问题？有哪些选择可以从本质上浓缩所有这些未来？
谢谢
【问题讨论】：
标签： database-migration liquibase
没有单一的答案，最有效的方法取决于您的环境、流程以及您想要削减它们的原因。
一般来说，我建议让您的变更日志增长，因为现有步骤是您已经测试、部署并且知道是正确的步骤。更改它们会带来风险，这总是可以避免的。保持变更日志不变还允许您继续以与旧实例相同的方式引导新的开发/质量保证数据库。
虽然拥有较大的更改日志会有一些性能损失，但 Liquibase 会尝试将其保持在最低限度，并且主要只是解析更改日志文件，然后从应该可以很好地扩展的 DATABASECHANGELOG 表中读取。由于liquibase update 通常很少运行，即使运行需要几秒钟也没什么大不了的。
话虽如此，有时清除您的变更日志是有道理的。最好的方法取决于您要解决的问题是什么。
最简单的方法通常是删除对最旧变更日志文件的包含引用。如果您知道所有数据库都已应用 ABC.xml 和 DEF.xml 中的更改集，您只需从主更改日志中删除对它们的引用，一切都会好起来的。 Liquibase 不关心 DATABASECHANGELOG 表中是否有“未知”的变更集。如果您想继续使用 ABC.xml 和 DEF.xml 来提升开发和 QA 环境，您可以创建第二个旧版“主 changelog.xml”，其中包含它们，并在需要时运行两个更改日志，或者确保旧版更改日志包含旧的更改日志和新的变更日志。
如果您不想完全删除 changeLog 引用，您可以手动修改现有的 changeSet。很多时候，只有一些更改可以对更新性能产生很大影响。例如，如果创建了索引然后删除了索引，则可以通过删除删除和创建更改集来跳过创建成本。同样，liquibase 不关心已经运行 changeSets 的数据库，也不会看到新的数据库。如果您有一些可能仍有索引的数据库并且您希望将其删除，则可以在删除 create changeset 后对 drop changeSet 使用 indexExists 前置条件。
前提条件检查也可能很昂贵，尤其是取决于数据库供应商。有时删除现在不需要的前置条件检查也可以提高性能。
【讨论】：
到目前为止，这对我们来说还不是问题。是的，你最终得到了很多包含但到目前为止我根本不在乎。我强烈建议不要删除任何旧的变更集或对其进行更改。尽量保持一切可复制的原样。
也许它有助于按应用程序的版本对变更集进行分组。我的意思是在您的 migrations.xml 文件中包含您的应用程序的每个版本的文件，其中包括您的“真实”变更集。这样，您还可以轻松找出哪个变更集属于您的应用程序的哪个版本。
【讨论】：