前阵子帮朋友装个老系统，对方翻出一张 SQL Server 2000 的光盘，结果双击 setup.exe，鼠标转了两圈就没了动静。我盯着屏幕等了五分钟，什么反应都没有，连个错误提示都没弹。这种静默失败最让人抓狂，因为完全不知道问题出在哪。后来我折腾了整整一下午，试了十几种办法才搞定。回头想想，SQL2000 安装没反应这事儿，在 2024 年其实一点都不稀奇——这款 20 年前的数据库软件，和现在的 Windows 系统之间隔着好几代补丁和安全策略，能顺利装上才是见鬼了。
先说最直接的兼容性问题。SQL2000 是在那个没有太多安全机制的时代设计的。现在的 Windows 10 或 11 默认开启了 UAC、内核隔离、堆栈保护等功能，安装程序在写入系统文件夹或注册表时会被拦截。但拦截得并不彻底，既没有弹出“拒绝访问”的提示，也没有把进程杀掉，而是让它卡在那儿。就好比想进一扇门，门锁着但没上锁，你推了一下没推开，然后站在那儿发呆。解决办法其实很简单：右键 setup.exe，选“以管理员身份运行”，再勾上“以 Windows XP SP3 兼容模式运行”。很多人觉得这两个选项太基础，但往往最基础的招最管用，我那次试完，安装界面立刻蹦了出来。
兼容模式不是万能药。有些电脑即使设置了兼容性，安装程序仍然没有反应。这时就要检查系统服务。SQL2000 安装时会调用 Windows Installer 服务，还会尝试启动 SQL Server 服务。如果 Windows Installer 被禁用或损坏，安装过程就会在后台默默失败。更隐蔽的是，有些精简版系统把 MSDTC 服务砍掉，而 SQL2000 的安装程序恰恰依赖这个分布式事务协调器。我见过最夸张的一次，是某台电脑的 “Windows Management Instrumentation” 服务被优化软件关掉，导致安装程序无法查询系统信息，直接卡死在检测环境那一步。解决方法是打开 services.msc，手动把这些服务改成自动并启动。这一步很多人想不到，因为错误日志里根本不会提示。
再往下挖，还有个更常见的坑：.NET Framework 版本冲突。SQL2000 本身使用的是 .NET Framework 1.0，但现在的 Windows 系统自带的是 4.8。高版本理论上兼容低版本，但实际操作中，安装程序在检测 .NET 环境时会去注册表里找特定路径和版本号。如果找不到 1.0 的注册表项，它就认为“没有环境”，随后停止安装。更糟的是，有些电脑装了多个 .NET 版本，但注册表被清理软件误删了某些键值，安装程序同样会罢工。解决方案是去微软官网下载 .NET Framework 1.0 的独立安装包，手动装一遍。注意，必须是 1.0，不能是 1.1 或 2.0。装完后，注册表里缺失的键值会补全，SQL2000 的安装程序就能识别了。这招我试过三次，两次成功，一次失败——失败的那台电脑是 64 位系统，而 .NET 1.0 对 64 位支持很差，只能换成虚拟机。
说到虚拟机，这其实是目前最稳妥的方案。既然物理机上装 SQL2000 困难重重，不如直接建个 Windows XP 或 Windows 2000 的虚拟机。VMware Workstation 或 VirtualBox 都行，分配 1 GB 内存、20 GB 硬盘就够了。虚拟机里装 SQL2000 几乎不会遇到兼容问题，安装过程比物理机顺畅十倍。而且虚拟机还有个好处：可以随时快照，装完系统后打上 SP4 补丁，再把数据库附加上去，万一搞砸了，恢复快照重来就行。我有个客户，公司里还有一套 2002 年的老 ERP 系统必须跑在 SQL2000 上，他们直接在 Windows Server 2003 虚拟机上运行，已经稳定三年。虚拟化技术把老软件的寿命延长了二十年，这比在物理机上硬扛靠谱得多。
虚拟机也有缺点：性能损耗和操作复杂度。如果数据库要跑高并发查询或磁盘 I/O 压力大，虚拟机里的 SQL2000 可能会慢得让人抓狂。另外，虚拟机的网络配置也容易出问题——选了 NAT 模式，局域网里的其他机器可能连不上；选了桥接模式，IP 地址又可能与现有网络冲突。我有个朋友图省事，直接用了 Hyper‑V 的默认设置，结果装完 SQL2000 后客户端死活连不上，后来发现是虚拟交换机没配置好，折腾了两天才搞定。所以如果决定用虚拟机，一定提前规划网络模式，最好把虚拟机的 IP 设置为静态，并确保防火墙放行 1433 端口。
还有一个很少有人提的坑：安装包本身损坏。SQL2000 的光盘在当年就很脆弱，稍微划伤就读不出来。现在网上下载的 ISO 镜像，很多是从老光盘翻录的，校验值不对。我下载过一个号称“完整版”的 ISO，解压后缺少一个叫 “sqlrun.msi” 的关键文件，结果安装程序启动到一半就停了。更隐蔽的是，有些镜像为了省空间，把帮助文档和示例数据库删掉，导致安装程序在复制文件阶段报错。解决办法是去正规渠道获取——虽然微软官方已不再提供 SQL2000 下载，但一些存档网站提供带校验和的版本。下载后用 MD5 工具核对哈希值，匹配后再安装。这一步花不了两分钟，却能避免浪费几个小时去排查根本不存在的环境问题。
说个偏方：修改系统时间。SQL2000 的安装程序在检测系统时间时，如果发现年份超过某个阈值（我记得是 2019 年），就会认为证书过期或时间戳无效，直接罢工。这听起来像 bug，但确实存在。我遇到过一台电脑，系统时间被设成 2025 年，结果安装程序连界面都不显示。把时间改回 2010 年，重启安装程序，瞬间就能跑了。装完后再把时间改回来，数据库运行不受影响。这招虽然有点歪门邪道，但在顽固案例里确实有效。不过要注意，改时间前最好断网，否则 Windows 会自动同步正确时间，白忙一场。
总结一下我踩过的坑：兼容模式、系统服务、.NET 版本、虚拟机方案、安装包完整性、系统时间，每个都可能成为拦路虎。SQL2000 这台老古董在 2024 年的 Windows 系统上安装，本质上是一场“你让一步我让一步”的谈判。需要多尝试几种组合，才能找到恰好能哄住它的配置。但话说回来，如果只是偶尔用一次，我建议直接放弃物理机，花十分钟装个虚拟机，省下的时间足够喝三杯咖啡。毕竟，和一个 20 年前的老软件较劲实在不值得——它早该退休了，只是我们舍不得扔。
