Flyway怎么对数据库脚本自动化管理

本篇内容介绍了“Flyway怎么对数据库脚本自动化管理”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

今天，探讨一个有趣的话题：我们可以通过 Git 来实现项目版本控制；通过 Jenkins 进行持续集成，那么对于数据库层面，我们仍然依赖于纯手工运行 SQL 脚本，对此，我们在多环境（开发环境、测试环境、预发环境、生产环境）中如何确保其 SQL 脚本的最新性和正确性？

众所周知，人工的操作非常容易出问题，我们应该让程序帮忙自动进行管理和迁移。今天，笔者推荐一款开源的数据库迁移工具 Flyway。

Flyway 不仅可以支持 MySQL，它也可以支持非常多其他的数据库。

事实上，Spring Boot 已经完美整合了 Flyway。对此，我们可以非常便捷地使用它。首先，我们引入 Maven 依赖。(注意的是，我们项目中还需要 spring-boot-starter-jdbc、 mysql-connector-java 依赖)

<dependency>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-core</artifactId>
</dependency>

此外，我们在 application.yml 中配置相关选项。Spring Boot 默认在 classpath://db/migration 目录下扫描Migration。这里，笔者通过 spring.flyway.locations 将其调整为 db/sql。

spring:
  flyway:
    enabled: true
    baseline-on-migrate: true
    locations: [classpath:db/sql]

当系统程序启动时，它会自动创建 flyway_schema_history 文件。(当然，也可以自己手动创建)。这张表是 Flyway 的元数据表， 其保存着每次 migration 的记录, 记录包含 migration 脚本的版本号和 SQL 脚本的 checksum 值。当一个新的 SQL 脚本被扫描到后, Flyway 解析该 SQL 脚本的版本号, 并和 metadata 表对比， 如果该 SQL 脚本版本更新的话, 将在指定的 DB 上执行该 SQL 文件, 否则跳过该 SQL 文件。

CREATE TABLE `flyway_schema_history` (
  `installed_rank` int(11) NOT NULL,
  `version` varchar(50) DEFAULT NULL,
  `description` varchar(200) NOT NULL,
  `type` varchar(20) NOT NULL,
  `script` varchar(1000) NOT NULL,
  `checksum` int(11) DEFAULT NULL,
  `installed_by` varchar(100) NOT NULL,
  `installed_on` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `execution_time` int(11) NOT NULL,
  `success` tinyint(1) NOT NULL,
  PRIMARY KEY (`installed_rank`),
  KEY `flyway_schema_history_s_idx` (`success`)
)

然后，我们在 db/sql 下手动创建一个初始化的 SQL 脚本：V1.1__INIT_DB.sql。

DROP TABLE IF EXISTS `tag`;

CREATE TABLE `tag` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `gmtCreate` date DEFAULT NULL,
  `gmtModified` date DEFAULT NULL,
  `title` varchar(32) DEFAULT NULL,
  `parentId` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

那么，在程序再次启动后，它会将其自动化发布到数据库中。   

这里，需要补充的知识点：Flyway 的版本比较规则。其采取左对齐原则，缺位用 0 代替。例如 1.1 比 1.0 版本高，1.1.1 比 1.1  版本高，而 1.1.01 和 1.1.1  版本一致。 并且，它们会按照版本排序且顺序执行。

此外，Flyway 不仅支持 DDL，也同时支持 DML（insert、update、delete）等。因此，我们可以再创建一个 V1.2__INSERT_TAG_DATA.sql 文件来验证一下。

INSERT tag(title, parentId) values('java', 0);
INSERT tag(title, parentId) values('spring', 0);

最后，我们在来一起探讨下Flyway 支持常见类型的 migration：

• Versioned migrations：数据库升级脚本

• Repeatable migrations：可重复执行，当脚本 checksums 改变时会重新执行。

• prefix: 前缀标识，默认值 V 表示 Versioned, R 表示 Repeatable

• version: 标识版本号, 由一个或多个数字构成, 数字之间的分隔符可用点.或下划线_

• separator: 用于分隔版本标识与描述信息, 默认为两个下划线__

• description: 描述信息, 文字之间可以用下划线或空格分隔

• suffix: 后续标识, 默认为.sql

总结一下，Flyway 通过元数据（flyway_schema_history）帮忙我们自动化维护和管理数据库的版本迁移。

“Flyway怎么对数据库脚本自动化管理”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！