前几天和一个做系统的朋友吃饭，他吐槽说公司那套老系统跑不动了，MySQL 生态越来越成熟。但迁移这件事听起来简单，实际操作却全是坑。
先说个真实案例。去年有个做电商的朋友，他们团队花了两个月迁移核心交易库，结果上线第一天就挂了。原因很简单：SQL Server 里用了大量的存储过程和触发器，这些在 MySQL 里要么语法不兼容，要么性能差距巨大。他们以为装个工具跑一遍就完事，结果吃了大亏。所以第一件事得说清楚：迁移不是简单的复制粘贴，而是给数据库“换芯”。你得先搞清楚两个数据库的脾气秉性。SQL Server 是微软家的“富家子弟”，闭源、收费、生态相对封闭但功能齐全；MySQL 是开源界的“平民英雄”，免费、开放、社区活跃但某些高级功能需要自己折腾。你要做的，是把前者依赖的商业特性代码改造成后者能跑通的逻辑。
数据类型转换是第一个坎。SQL Server 里的 DATETIME 精度是 3.33 毫秒，MySQL 的 DATETIME 默认到秒，但 5.6 版本后支持到微秒。听起来差别不大，但如果系统里有时间戳比对逻辑，就会出大问题。更头疼的是 NVARCHAR 和 VARCHAR。SQL Server 里 NVARCHAR 存 Unicode 字符，MySQL 里 VARCHAR 默认是 utf8mb4 编码，也能存 Unicode，但索引长度限制不一样：SQL Server 的页大小是 8KB，索引键最大 900 字节；MySQL 的 InnoDB 引擎页大小是 16KB，索引键最大 767 字节。如果你有长字符串字段建了索引，迁移后可能直接报错。我见过最惨的案例：一个日志表里有个字段存了 2000 个中文，在 SQL Server 里用 NVARCHAR(2000) 跑得好好的，迁到 MySQL 后 VARCHAR(2000) 直接超了索引限制，只能拆字段或改索引策略。
存储过程和函数是重灾区。SQL Server 的存储过程支持输出参数、表值参数、游标循环、异常处理，这些在 MySQL 里都有对应实现，但语法千差万别。比如 SQL Server 用 ，MySQL 用 （不用 @ 符号）。SQL Server 的 在 MySQL 里没有直接等价物，需要手动处理。更麻烦的是，SQL Server 支持 异常处理，MySQL 5.6 之前只能靠 ，5.6 之后才有 。如果存储过程里有复杂的事务嵌套和错误回滚，迁移时必须逐行重写。一个做 ERP 的朋友，他们系统里有 300 多个存储过程，每个平均 300 行，迁移团队花了三周才改完，测试又花了两周。他总结的经验是：先把存储过程导成文本，用正则批量替换常见语法差异，剩下的手工精调。但这只适用于相对简单的场景，碰到自定义函数、递归查询等，还是得靠人工编码。
分区表和索引策略也得调整。SQL Server 的分区表和 MySQL 的 InnoDB 分区表逻辑类似，但实现细节不同。SQL Server 支持分区函数、分区方案、分区对齐索引，MySQL 只支持 RANGE、LIST、HASH、KEY 四种分区类型。如果你用 SQL Server 的复合分区（比如先按时间分区，再按地域分区），MySQL 不支持这种嵌套，只能改成一维分区或用子分区模拟。索引方面，SQL Server 的聚集索引和非聚集索引存储方式不同，MySQL 的 InnoDB 聚集索引就是主键索引，非聚集索引的叶节点存的是主键值。如果主键是 UUID 这种随机值，MySQL 的写入性能会直线下降，因为每次插入都要调整 B+ 树结构。一个游戏公司迁移时没注意这点，结果线上玩家数据写入延迟从 5 毫秒飙升到 200 毫秒，最后只能把主键改成自增 ID，所有关联表全部重建。
工具选对了，能省一半功夫。市面上主流的迁移工具有三款：MySQL Workbench 自带的迁移向导、AWS DMS（数据库迁移服务）以及开源工具如 mydumper / myloader。MySQL Workbench 的迁移向导适合中小型数据库，能自动转换数据类型和部分存储过程，但碰到自定义函数和触发器就会卡住。AWS DMS 适合上云场景，支持增量同步和 CDC（变更数据捕获），但价格不便宜，而且需要先在 SQL Server 上开启日志捕获。我的建议是：先用工具做全量数据迁移，然后对比表结构和索引差异，手动修复不兼容的地方，再跑增量同步。但要注意，工具处理不了业务逻辑层面的差异。比如 SQL Server 里字段默认值是 ，MySQL 对应的是 ，工具能自动转换；但如果在存储过程里用了 ，MySQL 对应的是 ，工具同样可以处理。真正难的是那些隐含的业务逻辑，比如 SQL Server 中文默认按拼音排序，MySQL 按 Unicode 编码排序，如果系统依赖这种排序，就必须在查询里显式指定 。
性能调优是一道关。数据迁过去只是第一步，跑得动才是关键。SQL Server 和 MySQL 的调优思路完全不同。SQL Server 倚赖自动化管理，比如自动更新统计信息、自动创建索引提示；MySQL 则需要手动维护。最常见的问题是：迁移后同样的 SQL 在 MySQL 里慢十倍。原因可能是 MySQL 的查询优化器不够智能，或者索引建得不对。比如 SQL Server 里 和 的性能差异不大，但 MySQL 如果关联表没有索引， 会导致全表扫描。另一个坑是 MySQL 的临时表空间默认在磁盘上，如果查询使用大量临时表，性能会急剧下降。一个做报表系统的朋友，SQL Server 查询平均 2 秒完成，迁到 MySQL 后变成 20 秒。排查后发现是 MySQL 的 和 设置太小，临时表被写到磁盘，调大后降到 5 秒。还有字符集和排序规则，utf8mb4 编码的字符串比较比 latin1 慢很多，如果字段不需要存 emoji 表情，改成 latin1 能提升不少性能。
迁移完成后，别忘了做回归测试和灾备切换。有些坑只有在生产环境才能暴露出来。比如 SQL Server 的锁机制和 MySQL 的 MVCC（多版本并发控制）差异。SQL Server 默认读操作会加共享锁，写操作会阻塞读；MySQL InnoDB 默认读操作不加锁，写操作通过 undo log 实现事务隔离。如果业务代码依赖“读后写”的串行化，在 MySQL 里可能出现幻读，需要手动加 。还有一点：SQL Server 的日志文件可以自动扩展，MySQL 的 binlog 如果写满磁盘会直接报错。我见过最惨的案例：系统上线后每天产生 5 GB 的 binlog，运维没有监控磁盘空间，结果两周后磁盘满了，整个数据库挂掉，恢复花了 8 小时。所以迁移后第一件事是：配置 binlog 过期时间、监控磁盘使用率并设置告警。
总结一句：SQL Server 迁移到 MySQL，本质上是把一套成熟商业系统的“大脑”，移植到开源平台的“躯体”。这个过程需要技术、耐心和敬畏心。但一旦成功，你得到的不仅是省下的授权费，还有更灵活的架构和更低的运维成本。别把迁移当成任务，要把它当作系统的“第二次创业”。
