这事儿得从一次加班说起。那天凌晨两点，我盯着慢得像蜗牛爬的 Access 数据库，终于忍不住摔了鼠标。几十万条数据，查询一次要等十几秒，同事们都把 Excel 当成避难所。老板说：“你不是搞技术的吗？赶紧把这破玩意儿搬到 SQL Server 上去。”我答应了，心里却打鼓——Access 跟 SQL Server 就像自行车和跑车，结构设计相差好几个时代。但没办法，数据量上来了，Access 那 2 GB 的上限就像个定时炸弹，迟早会炸。
先说说准备工作。千万别以为把 Access 文件拖到 SQL Server 里就完事了，那跟把自行车轮胎强行装到跑车上一样，跑不起来。第一步，你得打开 SQL Server Management Studio，创建一个空数据库，这叫“接生婆”已经准备好了。然后，下载 SQL Server Migration Assistant（SSMA），微软自家的免费工具。安装时注意选对版本，比如要迁到 SQL Server 2019，就下对应的 SSMA。该工具会自动识别 Access 里的表、查询、表单，还能检测兼容性问题。我第一次用时，它报了一百多个警告，差点把我吓出心脏病。后来发现，大多是字段类型不匹配——Access 里那类“备注”字段，在 SQL Server 里得改成 nvarchar(max)，否则存不下长文本。
真正动手迁移时，最头疼的是数据类型映射。Access 有个“自动编号”字段，每次新增记录自动加 1，但在 SQL Server 里叫 IDENTITY，语法完全不同。还有“是/否”字段，Access 用 -1 和 0 表示真和假，SQL Server 却是 1 和 0，直接搬过去查询结果会乱套。更坑的是日期字段，Access 的日期范围是 100 年 1 月 1 日到 99 年 12 月 31 日，SQL Server 的 datetime2 虽然范围更宽，但默认格式是 YY‑MM‑DD，分隔符搞错就报错。我那次迁移时，表里出现了 “2023‑13‑01” 这种奇葩值——13 月，Access 居然能接受，SQL Server 直接罢工。后来只能写脚本，把非法日期全部改成 1900‑01‑01，并手动标记出来让业务部门核对。
关系和外键也是大坑。Access 里可以随便建关系，但 SQL Server 对参照完整性要求严格得多。比如订单表引用客户表，如果客户表里没有对应 ID，Access 可能睁只眼闭只眼，SQL Server 会直接拒绝插入。我迁移一个进销存系统时，发现 Access 里有一千多条订单引用了已删除的客户记录。按 SQL Server 的标准，这些都是孤儿数据。怎么办？要么删掉，要么补上虚拟客户。我和业务部门争了三天，最终决定保留数据，给这些孤儿记录建一个 “已删除客户” 的虚拟 ID。这个活儿不算技术，但涉及沟通，需要让业务方明白：不是数据库不行，而是以前的随意导致的。
性能优化是迁移后的重头戏。很多人以为搬完就大功告成，结果一上线查询比 Access 还慢。为什么？因为 Access 是文件型数据库，查询时直接读文件；SQL Server 是服务型，需要通过网络连接，还要处理锁、事务、日志。如果不建索引，就像让跑车在泥巴路上开。比如订单表没有对订单日期建索引，查询某个月的订单时，SQL Server 必须全表扫描，几百万行数据挨个看。建个非聚集索引后，查询时间从几十秒降到几毫秒。还有 Access 里常用的 “LIKE” 模糊查询，在 SQL Server 里最好改成全文索引，否则性能惨不忍睹。我把查询语句从 “WHERE Name LIKE '张%'” 改成 “WHERE Name >= '张' AND Name < '仝'”，速度提升了十倍。
安全性这块经常被忽视。Access 的数据库文件就是共享文件夹里的一个 .accdb 文件，谁都能复制走。SQL Server 必须设登录名、用户、角色、权限，麻烦但必须做。我见过有人把 SQL Server 的 sa 账户密码设成 “123456”，结果被黑客删光了表。迁移时最好重新规划权限：应用账户只给读写存储过程的权限，报表账户只给查询视图的权限，管理员账户才给全部权限。另外，别忘了备份策略。Access 里手动复制文件就行，SQL Server 则需要定期自动备份，还要做差异备份和事务日志备份。我制定的规则是：每天凌晨全量备份，每小时差异备份，每 15 分钟日志备份。硬盘空间紧张时，只保留最近 7 天的备份，但至少保留一个月的完整备份链。
说说那些“搬不动”的东西。Access 里的宏、模块、窗体、报表，SSMA 迁不了。必须在 SQL Server 里重新用 T‑SQL 写存储过程，或者用 SSRS 报表替代。我见过最惨的案例：一个老系统在 Access 里嵌了上百个 VBA 宏，用来做数据校验和自动化流程。迁移时没人了解这些宏的逻辑，一跑就报错，业务部门只能手工录入数据，效率比之前还低。所以迁移前一定要梳理清楚哪些功能是 Access 独有的，并用 SQL Server + 其他工具替代。比如用 PowerApps 做前端表单，用 Power Automate 做工作流，成本高但值得。毕竟，数据库迁移不是搬家，而是升级，不能只把旧家具搬进新房子，还要确认新房子能容纳这些家具。
说到底，Access 到 SQL Server 的迁移，技术只占 30%，剩下的 70% 是业务梳理、数据清洗和人员培训。别指望一天搞定，留足两周的缓冲期。先在小范围内试迁移，让业务部门用测试库跑一周，发现问题再改。上线当天，准备好回滚方案——把 Access 数据库原封不动地备份好，万一 SQL Server 出问题，至少能退回去。我那次迁移，上线后第三天就出了事：一个批处理作业没调好，把订单表的 “状态” 字段全更新成了 “已取消”。好在 Access 备份还在，花了四小时恢复了数据。老板说：“你小子留了一手啊。”我说，干这行必须给自己留条后路。数据库迁移不是炫技，而是求生。
