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

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

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

我们试一下：

新建一个 TypeORM 项目：

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

改下 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",
    },
});

安装用到的 mysql2:

npm install --save mysql2

在 mysql workbench 里创建这个 database：

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

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

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

跑一下：

npm run start

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

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

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

改下 Entity：

重新跑下：

npm run start

可以看到 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

生成了 “时间戳-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> {}
}

然后把 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",
    },
});

先在 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

可以看到，执行了 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

生成的 migration 文件如下：

用 migration:run 执行下：

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

然后再跑下 npm run start：

没啥问题。

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

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

我们在 User 里加一个字段：

@Column()
email: string

再执行下 migration:generate

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

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

跑下 migration:run

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

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

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

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

执行 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"

这样用起来就简单多了：

案例代码在小册仓库。

总结

开发环境我们会用 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 里的上次执行记录

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

上次更新:
贡献者: YNight