如何在已投产的现有生产环境数据库中使用TypeOrm？

完全可以在已经投产运行的MySQL生产库上使用TypeORM对接新平台，但绝对不能直接套用开发环境的默认配置连生产，必须落实一系列约束规则，否则极大概率引发现有线上业务故障。

必须严格遵守的核心规则 #

• 最优先级红线：强制关闭TypeORM的自动表结构同步能力，配置项synchronize必须设为false。这个功能是开发阶段省手动建表成本用的，应用启动时会自动对比代码里的Entity定义和数据库实际表结构，自动执行建表、改字段、加索引这类DDL操作。如果连生产时忘了关，只要Entity定义和线上现有表有一点不匹配——比如字段类型写错、漏配了现有字段、多定义了一个索引——应用启动瞬间就会直接修改生产表结构，轻则字段类型错配丢数据，重则大表DDL长时间锁表，直接把正在运行的老平台打挂，这是生产环境踩过无数次的经典坑。
• 做数据库账号的最小权限管控：给新平台单独创建专属的MySQL连接账号，这个账号绝对不能授予CREATE、ALTER、DROP、TRUNCATE这类DDL权限，只给业务实际需要的DML权限（比如对应表的SELECT、INSERT、UPDATE，DELETE权限可按需评估是否开放），从权限层兜底，哪怕代码配置出问题，也没有权限修改表结构、删库删表。
• 禁止在应用启动流程里加任何自动执行的schema变更、全量数据初始化逻辑。所有涉及生产库的表结构调整、批量数据订正，必须走现有的生产数据库变更流程，经过人工审核、提前备份、在低峰运维窗口执行。
• 如果要用TypeORM的Migration能力管理表结构变更，绝对不能配置为应用启动时自动执行迁移。所有迁移脚本必须先在和生产配置一致的测试环境完整验证，确认执行时长、锁影响、回滚方案都没问题后，再在运维窗口人工触发执行。

上线前额外注意事项 #

• 提前抓TypeORM实际生成的业务SQL做审核和压测，确认所有查询都命中正确索引，不存在全表扫描、大表无join条件这类慢查询问题。新平台的数据库连接池大小一开始要配置得保守一些，避免一上线就占满生产库的连接配额，影响老平台的正常请求。上线初期要重点监控数据库的CPU负载、连接数、慢查询、锁等待指标，出现异常第一时间切断新平台的数据库流量。
• 如果新老平台需要共同操作同一张业务表，必须提前对齐字段语义、写入规则，不要在新平台的Entity里随便映射线上不存在的字段，也不要随意修改现有字段的类型映射（比如把线上的varchar字段直接映射为Number类型），避免出现数据解析错误、精度丢失、乱码这类问题。如果两个平台存在并发写同一条数据的场景，还要提前评估锁冲突、逻辑覆盖的风险，避免产生脏数据。

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