迁移

副标题 / 摘要 数据库迁移不是“导出导入”这么简单。本文给出从 MySQL 迁移到 PostgreSQL 的可执行步骤、风险清单与回滚策略。 目标读者 负责数据库迁移的工程师 需要评估迁移成本的技术负责人 对兼容性风险敏感的团队 背景 / 动机 MySQL 与 PostgreSQL 在语法、类型、索引、事务语义上都有差异。 如果缺乏系统化迁移计划，很容易出现数据损坏或线上回滚。 核心概念 兼容性差异：类型、函数、SQL 语法 迁移策略：停机迁移 / 双写迁移 回滚策略：可验证与可恢复 实践指南 / 步骤 评估差异：数据类型、索引、函数、事务语义 准备迁移工具（pgloader / 自研 ETL） 双写验证（可选）：新旧库同时写 全量迁移 + 增量同步 切流与回滚预案 可运行示例 # 迁移工具示例（pgloader） pgloader mysql://user:pass@localhost/db postgresql://user:pass@localhost/db 解释与原理 迁移的核心是“数据一致性 + 业务可回滚”。 任何一次迁移都必须可验证、可回滚、可复现。 常见问题与注意事项 类型差异：MySQL 的 TINYINT 在 PG 中可能需改为 SMALLINT 大小写与排序规则：字符集/排序规则差异可能导致查询结果变化 时间精度：时间类型精度不同需特别检查 最佳实践与建议 迁移前做数据与查询基准 全程保留旧库，直到稳定期结束 自动化校验（行数、校验和） 小结 / 结论 MySQL 到 PostgreSQL 迁移是系统工程。 正确做法是：分阶段、可验证、可回滚。 ...

副标题 / 摘要 数据库 Schema 迁移是系统风险的高发点。本文给出可执行的迁移策略与检查清单。 目标读者 需要做数据库迁移的工程师 负责上线流程与稳定性的团队 做 DevOps / DBA 的开发者 背景 / 动机 很多线上事故来自“不可逆的 schema 变更”。 正确做法是分阶段、可回滚、可验证。 核心概念 前向兼容：新旧代码同时可用 可回滚：变更可撤销 灰度发布：逐步流量切换 迁移顺序：先扩展、后收缩 实践指南 / 步骤 先扩展再收缩（add column -> backfill -> cutover -> drop） 双写验证（新旧字段一致） 可回滚脚本 灰度切换 迁移后验证（行数/校验和） 可运行示例 -- 1) 扩展 ALTER TABLE users ADD COLUMN status_new VARCHAR(20); -- 2) 回填 UPDATE users SET status_new = status; -- 3) 切换代码使用新字段 -- 4) 收缩 ALTER TABLE users DROP COLUMN status; 解释与原理 “先扩展后收缩”能保证新旧版本共存，避免停机与回滚困难。 迁移过程中的双写与校验是降低风险的关键。 ...