数据库迁移需明确目标类型与数据量，准备一致环境；选用停机、增量或双写策略；处理跨库语法差异；严格验证结构、行数与数据，并分步灰度切换。
明确迁移目标和准备环境
先搞清楚要迁什么、往哪迁。是同类型数据库之间迁移（比如 SQL Server → SQL Server），还是跨类型（SQL Server → MySQL）？数据量多大？要不要改表结构？这些直接决定用哪种方案。环境方面，目标库得提前搭好，包括用户权限、字符集、时区等配置，最好跟源库保持一致，避免后续兼容问题。
选对迁移方式：停机、增量、双写三类策略
停机迁移适合小业务或可接受短时中断的场景。操作简单：备份源库 → 停服务 → 还原到目标库 → 切换连接。整个过程控制在几十分钟内，但必须选低峰期，比如凌晨 2–4 点，并提前公告。
增量迁移适合中大型系统。先做一次全量同步，再持续捕获源库的变更日志（SQL Server 用 CDC 或事务日志，MySQL 用 Binlog），把新增/修改/删除操作实时打到目标库。等延迟趋近于零时，再切流，停写源库。
双写迁移追求零停机。应用层同时写旧库和新库（新库写入可异步），历史数据用工具补全；再逐步把读流量从 10% 切到 100%，过程中随时可回滚；最后停写旧库，完成收尾。
处理结构与数据差异
跨数据库迁移（如 SQL Server → MySQL）必须处理语法和类型不兼容问题：
- NVARCHAR → VARCHAR，DATETIME → DATETIME 或 TIMESTAMP
- GETDATE() → NOW()，ISNULL() → IFNULL()，TOP 10 → LIMIT 10
- 存储过程、触发器、函数需重写，视图可能要调整字段别名和表达式
- 建议用 SQLines 或 MySQL Workbench 的 Migration Wizard 辅助转译，再人工校验关键逻辑
验证与切换上线
数据不是导完就完事。得验证三件事：结构是否一致、行数是否对得上、关键业务数据是否准确。可用脚本抽样比对主键+核心字段，或用 pt-table-checksum（MySQL）、自定义 checksum 查询（SQL Server）做一致性校验。
切换阶段建议分步走：先切只读查询 → 观察 1–2 小时 → 再切写入 → 全量观察 24 小时 → 最后下线旧库。DNS、配置中心或代理层（如 ProxySQL、ShardingSphere）都能辅助灰度切换，降低风险。
