数据库迁移

Serverless 函数 不应在每次冷启动时 CREATE TABLE。Schema 变更应像传统后端一样 版本化、可重复、可审计——Flyway / Liquibase 跑在 CI、一次性 Lambda 或独立 Job，与 orm-migrations 同一套纪律。

学习目标

• 理解迁移脚本与运行时 Handler 的职责分离
• 对比「CI 跑 Flyway」与「迁移专用 Lambda」
• 掌握多环境（dev/staging/prod）推广顺序

为什么迁移不能绑在 Handler 里

做法	问题
Handler 启动时自动 migrate	并发 invocation 竞态；冷启动变慢
手工改 prod 表	无版本记录，回滚困难
脚本进 Git + 流水线执行	✅ 与 ORM track 一致

-- V2__add_order_status.sql（Flyway 命名）
ALTER TABLE orders ADD COLUMN status VARCHAR(32) NOT NULL DEFAULT 'PENDING';

orm-migrations 讲的 Flyway/Liquibase 语义不变；变的是 执行环境 从「SSH 到 EC2」变成 GitHub Actions 或 CodeBuild。

Serverless 环境的执行方式

1. CI/CD 门禁（推荐）：合并 main 前，pipeline 对 staging RDS 跑 flyway migrate，测完再 prod
2. 迁移 Lambda：VPC 内、限 IAM、仅 CI 角色可 invoke；适合无长期 runner 的团队
3. RDS 控制台手工：仅实验，禁止 prod 常态

DynamoDB 无 SQL 迁移：用 CloudFormation/SAM 定义表；索引变更走 GSI 在线添加，见 ddb-gsi。

与部署顺序

1. flyway migrate（schema 向前兼容）
2. 部署新 Lambda（读新列、写新列）
3. 清理旧列（另一次迁移，可选）

向前兼容：先加列 nullable，再发代码，再删旧逻辑——避免「新代码 + 旧表」线上爆炸。

练习

• 写一条 Flyway 版本命名规范与 rollback 策略（Liquibase 亦可）
• 画 pipeline：PR → test → migrate staging → deploy Lambda
• 说明 DynamoDB 加 GSI 与 MySQL 加索引在「零停机」上的差异

小结

迁移是发布流程的一等公民，不是函数里的隐藏副作用。 下一课看 SAM / Serverless Framework 如何在本地模拟云端。