一、Flyway 是什么？
我們都知道，Git/ SVN 是代碼界的版本控制工具，那么，Flyway 就是一款數據庫界的版本控制工具，它可以記錄數據庫的變化記錄。
可能很多公司都是通過人工去維護、同步數據庫腳本，但經常會遇到疏忽而遺漏的情況，舉個簡單的例子：
我們在開發環境對某個表新增了一個字段，而提交測試時卻忘了提交該 SQL 腳本，導致出現 bug 而測試中斷，從而影響開發、測試的工作效率。
有了 Flyway，我們可以按版本約定，統一管理所有的 SQL 腳本變更，在所有環境自動同步數據庫，而無需人為手工控制，再也不用擔心因數據庫不同步而導致的各種環境問題。
支持的數據庫：
支持的運行方式：
支持的 7 個命令：
- Migrate（遷移）
- Clean（清理所有配置的對象）
- Info（顯示遷移狀態和細節）
- Validate（驗證遷移規則）
- Undo（撤消最近的遷移）
- Baseline（建立基線）
- Repair（修復遷移歷史表）
二、Spring Boot 集成 Flyway
Flyway 有社區開源免費版本和商業版本，本文以開源社區免費版，以及 Java API 的運行方式為示例進行演示下 Flyway Migrate 功能。
1、引入依賴
Flyway 幾乎是零依賴，最低的要求是：
-
JDK 1.7+
-
Jdbc Driver
Spring Boot 基礎教程就不介紹了，棧長之前寫過很多，不會的關注公眾號：Java技術棧，在后台回復：boot，歷史 Spring Boot 實戰教程我都整理好了。
本文演示環境：
這里僅展示 Spring Boot 之外的核心依賴：
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jdbc</artifactId>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>8.0.21</version>
</dependency>
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
<version>7.10.0</version>
</dependency>
</dependencies>
2、添加配置
Spring Boot 默認提供了對 Flyway 的自動配置：
org.springframework.boot.autoconfigure.flyway.FlywayAutoConfiguration
所以，Spring Boot 項目，我們僅僅只要提供對應的配置參數即可：
spring:
datasource:
driver-class-name: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://localhost:3306/flyway
username: flyway
password: 12345678
flyway:
locations:
- classpath:flyway
table: t_flyway_history
版本注意：
Spring Boot 2.5 及以上版本，如果使用了
spring.flyway.url進行定義，同時需要加上 username/ password 進行認證。
如果是第一次使用 Flyway，需要在 resources 目錄下創建配置文件中指定的 Flyway 遷移目錄：resources/flyway。
Flyway 也是約定大於配置的思想，以上 Flyway 的相關配置都可以不用寫，可以說是零配置，它們都有默認值：
- spring.flyway.locations: classpath:db/migration，用於掃描的遷移腳本目錄
- spring.flyway.table: flyway_schema_history，用於記錄所有的版本變化記錄
更多 Flyway 的參數配置可以參考這個類：
org.springframework.boot.autoconfigure.flyway.FlywayProperties
另外，最好是創建一套 Flyway 專門的數據庫表和用戶，和業務表、用戶分開，權利最小化。
三、遷移實戰
1、創建遷移腳本
然后在該目錄下創建遷移腳本，遷移腳本文件命名規則是：
V
__ .sql
注意：版本號后面是兩個下划線。
如棧長我第一次創建三個遷移腳本：
- V1.0.0__create_javastack.sql
- V1.0.1__insert_javastack.sql
- V1.0.2__update_javastack.sql
首先創建一個表，然后插入幾條記錄，再更新記錄，具體的 SQL 腳本內容就不貼上來了，完整的示例代碼已提交 Github：
OK，Spring Boot 集成 Flyway 及相關的腳本都弄完了，可以說是不能再簡單了，我們啟動系統驗證下腳本有沒有執行。
1）首次啟動
從啟動日志可以看出，已經遷移了 3 個腳本，並且將當前版本更新到了 v1.0.2：
查看數據庫，Flyway 歷史表和業務表也都已經創建：
可以看出歷史表記錄了 3 個腳本的遷移詳細記錄，業務表的數據也已經插入並得到更新：
2）不修改再次啟動
在不修改任何代碼的情況下再次啟動：
成功驗證了 3 個遷移腳本，打印了當前的版本號，但並沒有進行遷移，為什么？
因為這三個腳本都執行過遷移了，主要是版本號都小於等於當前版本號：1.0.2，所以不會進行遷移。
3）修改再次啟動
我們再新增兩個 SQL 腳本：
- V1.0.3__alter_javastack.sql
- V1.0.4__update_javastack.sql
首先新增兩個字段：note 和 time，然后再進行對應的數據更新。
我們再次啟動下：
成功遷移，當前版本來到了 v1.0.4。
查看數據庫：
note 和 time 字段已經創建，並得到更新。
2、創建重復遷移腳本
從上面的例子我們知道，只要目錄下的 SQL 腳本版本號大於當前版本號才會執行遷移，並且腳本都是一次性執行遷移的，如何做到可重復遷移呢？
Flyway 支持可重復遷移腳本，可重復遷移腳本文件命名規則是：
R__
.sql
R（Repeated），即：可重復的。
這里我創建一個更新 note 和 time 字段的遷移腳本：
- R__update_javastack.sql
1）首次啟動
我們再次啟動下：
從以上截圖可以看到，重復遷移腳本也已經成功執行了。
2）不修改再次啟動
如何確定能否重復執行遷移呢？
我們不修改任何代碼再次啟動下：
顯示沒有遷移的必要！！
那是因為我們沒有對重復遷移腳本做任何的修改，所以系統不會遷移！
3）修改再次啟動
我們再次改下腳本，把 note 后面加一個 ok，再次啟動下：
腳本經過修改后再次遷移成功了，說明可重復遷移腳本也需要經過改動才能再次進行遷移，Flyway 會進行腳本對比。
最后貼一下遷移腳本目錄：
這里我放到一個目錄進行演示，實際開發中可以放到多個目錄中區分維護。
四、遷移流程
OK，我們來梳理下遷移流程：
1）Flyway 會掃描配置的腳本目錄下的腳本文件；
2）如果歷史記錄表不存在，則新建歷史記錄表；
3）如果是一次性執行腳本（V），按版本號從小到大執行遷移腳本，與當前歷史表中的版本號做對比，大於當前版本號的腳本才會被執行遷移；
4）如果是可重復執行腳本（R），檢查腳本是否有變動，有變動的可重復腳本才會被執行遷移；
Flyway Migrate 遷移流程圖：
另外，我們也可以手動刪除遷移歷史表中的遷移記錄，這樣也可以達到讓一次性腳本再次執行的目的，但不建議在生產環境上進行使用。
五、總結
使用 Flyway 可以很方便的處理數據庫表結果、數據的版本遷移，使用簡單、自動化，大大提高生產力，再也不需要手工在控制台進行，那樣更容易出錯或者遺漏，畢竟人都是會經常犯錯的。
本文使用的是 Java API 的方式，在項目啟動時進行遷移，另外還有其他 3 種方式，文前有介紹，大家根據實際需要進行應用。
本文只是拋磚引玉，只介紹了 Flyway 中的 Migrate（遷移）環節，也是 Flyway 最主要的環節，另外還有其他 6 個環節，后續棧長在時間再進行分享，請陸續關注公眾號Java技術棧，公眾號第一時間推送。
本文完整示例代碼已上傳 Github：
更多細節可以參考官方文檔：
最后，你們有使用 Flyway 或者相關工具嗎？歡迎分享使用經驗～
覺得我的文章對你用收獲的話，動動小手，給個在看、轉發，原創不易，棧長需要你的鼓勵。
版權申明：本文系公眾號 "Java技術棧" 原創，原創實屬不易，轉載、引用本文內容請注明出處，禁止抄襲、洗稿，請自重，尊重大家的勞動成果和知識產權，抄襲必究。
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2021最新版)
2.終於靠開源項目弄到 IntelliJ IDEA 激活碼了，真香！
3.阿里 Mock 工具正式開源，干掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式發布，全新顛覆性版本！
覺得不錯，別忘了隨手點贊+轉發哦！