夜猫子的知识栈
神说要有光
2025-03-10
目录

生产环境为什么用TypeORM的migration迁移功能

前面我们基于 TypeORM 操作数据库都是开启了 synchronize，只要创建或者修改了 Entity，那就会自动创建表和修改表结构。

在开发时这样很方便，只要关注代码就好了，不用管修改表结构的事情。

# 但是在生产环境下，用 synchronize 很危险，很容易丢数据。

我们试一下：

新建一个 TypeORM 项目：

npx typeorm@latest init --name typeorm-migration --database mysql
1

改下 data-source.ts 的配置：

import "reflect-metadata";
import { DataSource } from "typeorm";
import { User } from "./entity/User";

export const AppDataSource = new DataSource({
  type: "mysql",
  host: "localhost",
  port: 3306,
  username: "root",
  password: "guang",
  database: "migration-test",
  synchronize: true,
  logging: true,
  entities: [User],
  migrations: [],
  subscribers: [],
  poolSize: 10,
  connectorPackage: "mysql2",
  extra: {
    authPlugin: "sha256_password",
  },
});
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

安装用到的 mysql2:

npm install --save mysql2
1

在 mysql workbench 里创建这个 database：

指定名字和字符集，点击 apply.

或者也可以执行这个 sql 来创建：

CREATE SCHEMA `migration-test` DEFAULT CHARACTER SET utf8mb4 ;
1

跑一下：

npm run start
1

可以看到，会自动创建 Entity 对应的表：

在 mysql workbench 里也可以看到这个表：

把插入数据的代码注释掉：

改下 Entity：

重新跑下：

npm run start
1

可以看到 TypeORM 检测到 Entity 的变更，修改了表结构：

在 mysql workbench 里可以看到，之前的 age 列就没了：

数据是不是就全丢了！

更何况跑 nest 项目的时候都是用 npm run start:dev，代码改动立刻重新跑，所以很容易丢数据。

所以说，synchronize 在开发环境下确实很方便，但是在生产环境下不能用，不安全。

那不用 synchonize 用啥呢，手动去数据库执行 sql 么？

那倒也不用。

# 可以用 TypeORM 的 migration 功能。

migration 是迁移的意思，其实前面的 create table、alter table 这些都是 migration：

只不过之前是自动跑，而现在我们要管理起来，手动跑。

# typeorm 提供了一个 cli，执行 migration:create 的命令：

npx ts-node ./node_modules/typeorm/cli migration:create ./src/migration/Aaa
1

生成了 “时间戳-Aaa.ts” 文件，这个就是放迁移代码的：

迁移就是 create table、alter table 这些。

我们在 mysql workbench 里导出下建表 sql 语句：

点击左侧的 Data Export，选中要导出的表，指定一个 sql 文件保存位置，点击 Export。

可以看到，生成的 sql 里就包括了 create table 建表语句和插入数据的 insert into 语句：

# 我们把建表 sql 拿过来：

import { MigrationInterface, QueryRunner } from "typeorm";

export class Aaa1708136448263 implements MigrationInterface {

    public async up(queryRunner: QueryRunner): Promise<void> {
        await queryRunner.query(`
            CREATE TABLE user (
                id int NOT NULL AUTO_INCREMENT,
                firstName varchar(255) NOT NULL,
                lastName varchar(255) NOT NULL,
                PRIMARY KEY (id)
            ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
        `)
    }

    public async down(queryRunner: QueryRunner): Promise<void> {
    }

}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# 然后把 synchronize 关掉，用 migration 来手动建表：

import "reflect-metadata";
import { DataSource } from "typeorm";
import { User } from "./entity/User";

export const AppDataSource = new DataSource({
  type: "mysql",
  host: "localhost",
  port: 3306,
  username: "root",
  password: "guang",
  database: "migration-test",
  synchronize: false,
  logging: true,
  entities: [User],
  migrations: ["./src/migration/**.ts"],
  subscribers: [],
  poolSize: 10,
  connectorPackage: "mysql2",
  extra: {
    authPlugin: "sha256_password",
  },
});
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

先在 mysql workbench 里把之前的表删掉：

把 index.ts 注释放开，但 age 去掉：

然后再跑 npm run start

这时候因为 synchronize 关掉了，不会自动建表，所以 报错了：

然后我们用 migration:run 来手动建表：

npx ts-node ./node_modules/typeorm/cli migration:run -d ./src/data-source.ts
1

可以看到，执行了 migration 里的 create table 语句。

这时候数据库中就有这个表了：

并且还在 migrations 表里记录了什么时间执行了什么迁移：

# 这时候再跑 npm run start

这时候 insert、select 就都成功了。

生产环境，我们不会用 synchronize 自动同步，就是用的 migration 的方式来建表。

但是导出建表 sql 再复制到 migration 的 up 方法里挺麻烦的。

# 有没有简便的方法呢？

# 有，这就是 migration:generate 命令。

把这两个表删掉：

把之前那个 migration 也删掉：

# 我们这次用 migration:generate 来生成：

npx ts-node ./node_modules/typeorm/cli migration:generate ./src/migration/Aaa -d ./src/data-source.ts
1

生成的 migration 文件如下：

# 用 migration:run 执行下：

npx ts-node ./node_modules/typeorm/cli migration:run -d ./src/data-source.ts
1

# 然后再跑下 npm run start：

没啥问题。

这样，就不用自己写 migration 文件了，就很方便。

# 当然，不只是建表算是 migration，修改表结构也算。

我们在 User 里加一个字段：

@Column()
email: string
1
2

再执行下 migration:generate

npx ts-node ./node_modules/typeorm/cli migration:generate ./src/migration/Bbb -d ./src/data-source.ts
1

这时候生成的 migration 就是 alter table 语句。

跑下 migration:run

npx typeorm-ts-node-esm migration:run -d ./src/data-source.ts
1

在 migrations 表里记录了 Aaa 跑过，所以这次只会跑 Bbb 的 migration。

# 可以跑 migration 也同样可以撤销：

npx ts-node ./node_modules/typeorm/cli migration:revert -d ./src/data-source.ts
1

执行 migration:revert 会执行上次的 migration 的 down 方法，并且从 migrations 表里删掉执行记录。

# 再次 revert，会撤销上一次的 migration，删掉 user 表：

所以说，每一次的 migration 都是可控的，可以手动执行、也可以撤销。生产环境我们就是用 migration 来修改表结构，而不是 synchronize

# 此外，每次都输这么长串命令也太麻烦了，我们可以把它封装成 npm scripts：

 "migration:create": "npm run typeorm -- migration:create",
  "migration:generate": "npm run typeorm -- migration:generate -d ./src/data-source.ts",
  "migration:run": "npm run typeorm -- migration:run -d ./src/data-source.ts",
  "migration:revert": "npm run typeorm -- migration:revert -d ./src/data-source.ts"
1
2
3
4

这样用起来就简单多了：

案例代码在小册仓库 (opens new window)。

# 总结

开发环境我们会用 synchronize 来同步 Entity 和数据库表，它会自动执行 create table、alter table，不用手动修改表结构，很方便。

但是它并不安全，因为很容易丢失数据。所以生产环境下我们会把它关掉，用 migration 来管理。

migration 就是把 create table、alter table 等封装成一个个的 migration，可以一步步执行、也可以一步步撤销回去。

有 4 个常用命令：

  • migration:create：生成空白 migration 文件
  • migration:generate：连接数据库，根据 Entity 和数据库表的差异，生成 migration 文件
  • migration:run：执行 migration，会根据数据库 migrations 表的记录来确定执行哪个
  • migration:revert：撤销上次 migration，删掉数据库 migrations 里的上次执行记录

这样就把生产环境里的建表和修改表的操作管理了起来。

编辑 (opens new window)
上次更新: 2025/8/6 16:38:56
TypeORM保存任意层级的关系
Nest 项目里如何使用 TypeORM 迁移

← Nest 项目里如何使用 TypeORM 迁移→

最近更新
01
IoC 解决了什么痛点问题？
03-10
02
如何调试 Nest 项目
03-10
03
Provider注入对象
03-10
更多文章>
Copyright © 2019-2025 Study | MIT License