把 SQL Server 的数据搬到 MySQL，最直接的办法不是写代码，而是用工具。我见过太多人一上来就打开 SSMS 导出 CSV，再往 MySQL 里 LOAD DATA，结果遇到中文乱码、日期格式炸裂、自增主键冲突，折腾一整天。其实有一条更稳的路：用 Navicat 或 DBeaver 的“数据传输”功能，选好源库和目标库，勾选“遇到错误继续”，让它自己跑。前提是两边的表结构已经建好——这一步才是真正花时间的地方。

数据类型是最先卡住的地方。SQL Server 的 NVARCHAR(MAX) 对应 MySQL 的 LONGTEXT，但很多人直接写成 VARCHAR(255)，截断数据不说，还悄悄丢了表情符号。更隐蔽的是 DATETIME2，MySQL 的 DATETIME 精度只到秒，而 SQL Server 默认保留 7 位小数。我上次迁移一个日志表，时间戳全变成同一秒，查问题时差点把头发薅光。解决办法是 MySQL 用 DATETIME(6)，或者干脆存 BIGINT 时间戳。

自增主键是另一个坑。SQL Server 的 IDENTITY 在 MySQL 里对应 AUTO_INCREMENT，但如果你用 Navicat 的“结构同步”自动转换，它经常把 IDENTITY 变成普通 INT。迁移完插入新数据，主键全是 0，直接报重复键错误。手动改表结构更靠谱：ALTER TABLE xxx MODIFY id INT AUTO_INCREMENT PRIMARY KEY; 但记得先删掉原来的主键约束，不然会冲突。

字符集问题比想象中顽固。SQL Server 默认用 Chinese_PRC_CI_AS 排序规则，MySQL 这边如果建库时用了 utf8mb4，迁移后中文正常，但 ORDER BY 的排序结果可能不一样。比如“张三”和“李四”，SQL Server 按拼音排，MySQL 按 Unicode 码点排。业务代码里如果有依赖排序的逻辑，得提前测。我一般会在迁移后跑一遍关键查询，对比两边结果集，差一行都不行。

存储过程和触发器基本没法直接搬。T-SQL 的 @@IDENTITY、TOP、ISNULL 在 MySQL 里要换成 LAST_INSERT_ID()、LIMIT、IFNULL。更麻烦的是 MERGE 语句，MySQL 用 INSERT ... ON DUPLICATE KEY UPDATE 替代，但语法逻辑完全不同。我建议先迁移表和数据，存储过程单独重写——别指望自动化工具，它们生成的代码能跑，但性能差得离谱。

数据量大的时候，别用图形界面。Navicat 传 500 万行以上会卡死，内存直接爆。换成 mysqldump 配合 --compatible=mssql 参数？不行，那个参数是给 MySQL 导出用的。正确做法是用 SQL Server 的 bcp 导出为文本，再用 mysqlimport 并行导入。或者上 Kafka 做流式同步，但那是另一个量级的工程了。小表随便折腾，大表必须走命令行。

迁移完别急着删源库。跑一周双写，或者至少保留只读权限。我见过有人迁移完直接下线 SQL Server，结果第二天发现某个报表的 GROUP BY 结果对不上——因为 MySQL 的 ONLY_FULL_GROUP_BY 模式默认开启，而 SQL Server 允许选择非聚合列。这种坑，只有跑起来才知道。