> For the complete documentation index, see [llms.txt](https://ldbmcs.gitbook.io/java/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ldbmcs.gitbook.io/java/shu-ju-ku-39/database-version-control/flyway/how-flyway-works.md).

# How Flyway works

> 转载：[How Flyway works](https://flywaydb.org/documentation/getstarted/how)

The easiest scenario is when you point **Flyway** to an **empty database**.

![2021-04-16-yXbUaP](https://image.ldbmcs.com/2021-04-16-yXbUaP.jpg)

It will try to locate its **schema history table**. As the database is empty, Flyway won't find it and will **create** it instead.

You now have a database with a single empty table called `flyway_schema_history` by default:

![2021-04-16-GRpvYo](https://image.ldbmcs.com/2021-04-16-GRpvYo.jpg)

This table will be used to track the state of the database.

Immediately afterwards Flyway will begin **scanning** the filesystem or the classpath of the application for **migrations**. They can be written in either Sql or Java.

The migrations are then **sorted** based on their **version number** and applied in order:

![2021-04-16-k0Nb9t](https://image.ldbmcs.com/2021-04-16-k0Nb9t.jpg)

As each migration gets applied, the schema history table is updated accordingly:

**flyway\_schema\_history**

| installed\_rank | version | description   | type | script                   | checksum   | installed\_by | installed\_on         | execution\_time | success |
| --------------- | ------- | ------------- | ---- | ------------------------ | ---------- | ------------- | --------------------- | --------------- | ------- |
| 1               | 1       | Initial Setup | SQL  | V1\_\_Initial\_Setup.sql | 1996767037 | axel          | 2016-02-04 22:23:00.0 | 546             | true    |
| 2               | 2       | First Changes | SQL  | V2\_\_First\_Changes.sql | 1279644856 | axel          | 2016-02-06 09:18:00.0 | 127             | true    |

With the metadata and the initial state in place, we can now talk about **migrating to newer versions**.

Flyway will once again scan the filesystem or the classpath of the application for migrations. The migrations are checked against the schema history table. If their version number is lower or equal to the one of the version marked as current, they are ignored.

The remaining migrations are the **pending migrations**: available, but not applied.

![2021-04-16-m6SvTL](https://image.ldbmcs.com/2021-04-16-m6SvTL.jpg)

They are then **sorted by version number** and **executed in order**:

![2021-04-16-WyhNWk](https://image.ldbmcs.com/2021-04-16-WyhNWk.jpg)

The **schema history table** is **updated** accordingly:

**flyway\_schema\_history**

| installed\_rank | version | description   | type | script                   | checksum   | installed\_by | installed\_on         | execution\_time | success |
| --------------- | ------- | ------------- | ---- | ------------------------ | ---------- | ------------- | --------------------- | --------------- | ------- |
| 1               | 1       | Initial Setup | SQL  | V1\_\_Initial\_Setup.sql | 1996767037 | axel          | 2016-02-04 22:23:00.0 | 546             | true    |
| 2               | 2       | First Changes | SQL  | V2\_\_First\_Changes.sql | 1279644856 | axel          | 2016-02-06 09:18:00.0 | 127             | true    |
| 3               | 2.1     | Refactoring   | JDBC | V2\_1\_\_Refactoring     |            | axel          | 2016-02-10 17:45:05.4 | 251             | true    |

**And that's it!** Every time the need to evolve the database arises, whether structure (DDL) or reference data (DML), simply create a new migration with a version number higher than the current one. The next time Flyway starts, it will find it and upgrade the database accordingly.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://ldbmcs.gitbook.io/java/shu-ju-ku-39/database-version-control/flyway/how-flyway-works.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.