TypeOrm重启服务器时Notifications表无法正确重建的问题咨询

问题现象 #

• 本地执行 npm run start 启动 Node 服务后，TypeOrm 同步数据时，仅 Notifications 表重建中途失败，仅生成 3 列（预期 10 列），后续操作该表触发 ER_BAD_FIELD_ERROR
• 删除 Notifications 表后重启服务，同步完全正常，其他表无异常

DataSource 配置 #

type: "mysql",
host: process.env.MYSQL_HOSTNAME,
port: 3306,
username: process.env.MYSQL_USERNAME,
password: process.env.MYSQL_PASSWORD,
socketPath: process.env.MYSQL_SOCKET_PATH,
database: process.env.MYSQL_DATABASE,
synchronize: true,
logging: false,
connectTimeout: 20000,
dropSchema: false,
entities: [
  Users,
  Notifications,
  etc...
],
migrations: [],
subscribers: [], 
});

Notifications 实体代码 #

@Index("notifications_id_UNIQUE", ["id"], { unique: true })
@Index("createdAt", ["createdAt"])
@Index("userId", ["userId"])
@Entity("notifications", { schema: "xxx", orderBy: {
  createdAt: "DESC",
} })
export class Notifications { 
  @PrimaryGeneratedColumn({ type: "int", name: "id" })
  id: number;

  @Column("varchar", { name: "notificationId", nullable: false, unique: true })
  notificationId: string;

  @Column("tinyint", { name: "notificationType", nullable: true })
  notificationType: number | null;

  @Column("text", { name: "message", nullable: true })
  message: string | null;

  @Column("varchar", { name: "country", nullable: true, length: 2 })
  country: string | null;

  @Column("varchar", { name: "userId", nullable: true })
  userId: string | null;

  @Column("tinyint", { name: "contentType", nullable: true })
  contentType: number | null;

  @Column("varchar", { name: "contentId", nullable: true })
  contentId: string | null;

  @Column("bigint", { name: "createdAt" })
  createdAt: number;
  
  @Column("tinyint", { name: "isRead", default:0, nullable: false })
  isRead: number;
}

问题根源分析 #

1. 现有表结构与实体定义冲突

   • 原 Notifications 表可能存在字段类型、约束与实体不匹配的情况，比如 createdAt 实体定义为 bigint，但原表中是 datetime 类型，TypeOrm 在尝试同步变更时无法自动转换，导致同步中断
   • notificationId 实体设置为非空且唯一，如果原表中已有数据但无该字段，同步时无法为已有行填充符合要求的唯一值，触发约束冲突导致同步停止

2. 索引变更处理失败

   • 实体中定义的索引（如 notifications_id_UNIQUE、createdAt 索引）与原表中已有的索引存在命名重复或结构冲突，TypeOrm 处理索引变更时抛出错误，中断整个表的同步流程

3. TypeOrm synchronize 模式的局限性

   • synchronize: true 仅适合开发环境，对已有表的复杂变更（如新增带约束字段、修改字段类型）支持不完善。当表中存在数据时，同步操作可能因为无法满足新约束而中途失败，仅完成部分字段的创建

4. 数据库锁或权限问题

   • 服务启动时，Notifications 表可能被其他进程持有锁，导致 TypeOrm 无法执行完整的 ALTER TABLE 操作
   • 数据库用户缺少 ALTER TABLE 等修改表结构的权限，导致同步操作中途被终止

验证与解决建议 #

• 开启 TypeOrm 的 logging: true，查看同步时生成的 SQL 语句及错误日志，定位具体失败的步骤
• 手动对比原表结构与实体定义，找出类型、约束不一致的字段并修正
• 开发环境下，若经常遇到同步问题，可临时设置 dropSchema: true（注意会清空所有数据），或每次修改实体后手动删除对应表
• 生产环境禁用 synchronize: true，改用 TypeOrm 迁移脚本管理表结构变更
• 检查数据库用户权限，确保拥有修改表结构的权限，同时避免服务启动时其他进程占用目标表

内容的提问来源于stack exchange，提问作者jennie788