现在 H2 1.4 已经完成测试，我想将旧的 1.3.175 数据库迁移到 1.4.195。
背景信息：
那么，推荐的迁移方式是什么？
其他方面/额外问题：
我应该启用 MVStore 还是坚持使用 PageStore（优点/缺点）？哪一个提供更好的性能（多线程对我来说并不重要），哪一个更好的稳定性，尤其是对OutOfMemoryErrors的弹性？
【问题讨论】：
标签： java database migration h2
@Steve McLeod 的回答很中肯。为了完整起见，以下是确切的命令：
//Do a backup of current .h2.db file
//Connect to current DB with same URL as always
SCRIPT TO 'fileName'
//Rename the .h2.db to something else, possibly another backup
//Connect to database with same URL as before. The new MVStore engine will be chosen by default, and the .mv.db file will be created
RUNSCRIPT FROM 'fileName'
此外，如果您更喜欢为此使用 H2 jar，请参阅 Thomas 的答案（1 和 2）。具体对应的类为org.h2.tools.Script和org.h2.tools.RunScript
【讨论】：
使用 1.3.175 创建的数据库可以使用 1.4.195 读取和打开，无需任何额外工作。 H2 会自动检测到它正在使用 Page Store 并对其进行处理。这样做不会有任何问题。
这样做的好处是，在开发 MVStore 的同时，Page Store 继续获得性能改进和错误修复。因此，带有 Page Store 的 H2 已成为一个极其稳定的数据库存储。
目前还没有将数据库从使用页面存储转换为使用 MVStore 的自动升级过程。如果您确实想这样做，则需要手动进行。使用最新的 H2 Jar，使用 H2 的 SCRIPT 命令从 1.3 数据库中导出 SQL，然后使用 RUNSCRIPT 到新创建的 1.4.195 数据库中。
如果您的 H2 JDBC URL 未明确指定 ;mv_store=false，请注意 H2 将首先查看页面存储数据库是否已存在。如果没有，那么它将创建一个 MVStore 数据库。这对您、您的应用程序和您的用户来说都是无缝的。您会注意到的唯一表面区别是磁盘上的数据库文件具有不同的文件扩展名。
最后，一个建议。如果您的客户数据库很大，请考虑仅使用页面存储。我是H2的重度用户。 （我基于 H2 构建的商业产品有数千名用户，他们通常拥有数 GB 大小的数据库。）我仍然为所有客户使用页面存储，即使我使用的是最新的 H2 Jar。随着数据库变大，MVStore 仍然存在一些性能问题。随着时间的推移，我希望能够找出问题的原因并加以解决。
【讨论】：