纪环我到现在还记得帮同事装 SQL Server 2019 那个下午。系统是全新的 Windows 11，安装包是官网现下的 ISO，一切看起来都很完美，然后情况就来了——进度条卡在“数据库引擎服务”，转了一会儿直接弹红叉，报错提示里躺着一串 C:\Users\xxx\AppData\Local\Temp 路径，后面跟着一句 Cold Feet 意味十足的 "The required MSI package ... cannot be found"。那一刻我就知道，SQL Server 的安装从来不是“下一步下一步”那么简单。
这篇文章我会把 SQL Server 安装过程中我实际踩过、以及这些年帮人收拾过的奇葩报错好好理一理。从环境准备到安装中段，从版本特有问题到日志排查，每个报错我都会讲清楚背后的逻辑链，告诉你为什么会出现，以及最稳的处理方法。内容适合刚接触 SQL Server 的初学者，也适合那些被安装问题卡住过、想彻底搞懂原理的运维和数据岗朋友。
1. 别急着点下一步：安装前的三道检查
很多人装 SQL Server 失败，根源不在于安装过程本身，而是开始之前就已经埋了雷。我在处理问题的时候反复确认过：绝大多数安装失败案例，只要做好安装前检查，至少有六成可以避免。
1.1 环境自检清单：运行库、服务与权限
SQL Server 安装程序对系统的依赖比想象中要多。很多表面上的安装失败，追根溯源其实是 .NET Framework 缺失、VC++ 运行库版本不对，或者 Windows Installer 服务被禁用。
先说 .NET Framework。SQL Server 2016 需要 .NET 4.6，2017 需要 4.6 以上，2019 需要 4.7.2，2022 需要 4.7.2 或更高。Win10 和 Win11 一般自带新版 .NET，但如果你的系统是精简版、或者常年不更新，装 SQL Server 的时候就非常容易在“安装程序支持文件”这一步卡住。建议在安装前手动确认：控制面板 → 程序和功能 → 启用或关闭 Windows 功能 → 勾选“.NET Framework 3.5”和“.NET Framework 4.8”。
VC++ 运行库同样容易被忽略。SQL Server 安装包会自动安装它依赖的 VC++ Redistributable，但如果你系统里已经有了旧版本，或者运行库被某些清理软件误删，安装程序可能不认为需要重新安装，最后在“数据库引擎服务”阶段崩溃。我的习惯是：安装前直接装好 VC++ 2015-2022 Redistributable x64/x86 两个版本，避免安装程序抽风。
还有 Windows Installer 服务。这个服务如果没有正常运行，任何 MSI 包的安装都无从谈起。你可以在服务管理器里检查 Windows Installer（msiserver）的启动类型，确保它是“手动”或“自动”，并且没有处于禁用状态。
最后是最重要的一项——权限。安装 SQL Server 必须使用本地管理员账户，并且安装程序必须以管理员身份运行。右键点击 setup.exe，选择“以管理员身份运行”，看起来是个非常基础的操作，但很多人在实际安装时用的是普通账号，或者双击运行没有提权，导致安装程序在写注册表、创建服务时被系统拒绝，报错完全没有规律可循。
1.2 安装包的真伪与版本来源隐患
再来说安装包。这绝对是新手最常踩的坑之一。SQL Server 的 ISO 文件动辄几个 GB，很多人在非官方渠道下载，或者从网盘拿到经过二次打包的镜像。这些镜像可能存在几个问题：一是文件被修改过，安装时会报文件哈希错误；二是镜像里可能压缩了多个版本，解压不完整会导致 MSI 包缺失；三是某些渠道提供的所谓“企业版”其实是评估版，装完只有 180 天使用期，到期后服务直接罢工。
版本选择上也要提前想清楚。SQL Server 的版本大概分三类：Express（免费但功能和性能受限）、Developer（免费，功能完整但不能用于生产）、Standard 和企业版（收费）。我见过很多人下载了企业版，装到一半要求输入密钥，或者找不到 ISO 里对应的镜像，最后卡住不动。其实正确的做法是：如果只是学习和开发，直接下载 Developer 版最省心；如果是要部署生产环境，从正规渠道获取标准版或企业版。
这里还有一个容易被忽略的点：安装包和操作系统架构必须匹配。64 位系统装 64 位的 SQL Server，32 位系统只能装 32 位（但 32 位 SQL Server 2008 之后的版本已经很少见了）。如果你在 64 位系统上尝试安装 32 位的 SQL Server 2019，会在“计划操作”阶段直接报错。
1.3 利用系统配置检查器排查前置风险
SQL Server 安装中心自带一个“系统配置检查器”（System Configuration Checker），这个工具会在你真正开始安装之前跑一遍系统检测，看看有没有阻止安装的问题。很多人跳过这一步，直接进安装向导，结果装到一半才暴露问题，处理成本高得多。
建议在安装中心第一步就运行系统配置检查器，并重点看这几项：是否包含重启挂起（PendingReboot）；磁盘空间是否充足；.NET Framework 是否满足要求；Windows 版本是否符合 SQL Server 的版本要求。如果 SCC 报红，先解决它报的问题，再继续安装。
注意：SCC 不是万能的。它只检查一些基础项，并不会检查所有潜在问题（比如 Temp 目录权限、注册表权限），所以 SCC 全绿也可能安装失败。但 SCC 报错一定要先处理，这是经验。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 安装过程中最常逼疯人的五个报错
前面铺垫了这么多前置工作，现在进入正题。安装过程中遇到的报错五花八门，但有几种出现频率极高，我把它们单独列出来讲透。
2.1 The required MSI package 找不到：Temp 路径背后的门道
这是本文开头那个场景的完整报错信息，常见形式类似：
code复制There was an error setting up private registry properties for the SQL Server product. The required MSI package 'C:\Users\86187\AppData\Local\Temp\...' cannot be found.
或者：
code复制Microsoft SQL Server 安装失败。 The required MSI package 'C:\Users\xxx\AppData\Local\Temp\...' ...
先解释一下为什么报错信息里会出现 Temp 路径。SQL Server 安装程序在启动时会把一些依赖的 MSI 包和资源文件解压到当前用户的 Temp 目录下，后续安装步骤再从这个目录读取这些包。整个解压和读取过程依赖于几个条件：Temp 目录存在且有读写权限；磁盘空间足够；没有安全软件拦截解压出来的文件。
最常见的情况是 Temp 目录权限异常。如果你的 Windows 用户名是中文，或者用户目录经过迁移、权限被改过，SQL Server 安装程序在往 Temp 写文件时可能没有写权限，或者写进去了但读取时被拦截。另外，一些“清理垃圾”工具会把 Temp 目录里的临时文件清掉，如果正好在安装过程中运行了这类工具，MSI 包被删掉，安装自然就失败了。
解决方法分几步走。第一步，确认 Temp 目录存在并且当前用户有完全控制权限。直接在文件资源管理器地址栏输入 %temp%，如果提示找不到目录，先手动创建。第二步，清理 Temp 目录的空间，至少留出 10GB 以上的可用空间，SQL Server 解压出来的临时文件加上数据库文件，占用比想象中大。第三步，安装过程中暂时关闭杀毒软件和安全卫士的实时防护，防止误删解压出来的 MSI 文件。如果以上都试过还是报错，可以尝试切换用户：新建一个管理员账户，用新账户运行安装程序，往往能绕开旧账户权限的坑。
2.2 数据库引擎服务启动失败的排查链路
SQL Server 安装过程大致是：复制文件 → 配置服务 → 启动服务 → 完成配置。在“配置服务”或“启动服务”环节失败，是比较常见的安装中断点。报错通常是：
code复制数据库引擎服务无法启动。
或者：
code复制服务 'MSSQLSERVER' 启动失败。
遇到这种报错，先不要急着重装。SQL Server 服务启动失败的核心原因通常集中在三处：服务账户权限、端口冲突、系统环境异常。
先说服务账户。SQL Server 默认使用 NT Service\MSSQLSERVER 这类虚拟账户运行，安装程序会自动分配权限。但如果你在安装时手动指定了服务账户（比如域账户或者某个本地用户），而这个账户没有“作为服务登录”的权限，或者密码不符合策略，服务就会启动失败。排查方法很简单：打开服务管理器，找到 SQL Server (MSSQLSERVER) 服务，查看“登录”选项卡，确认账户是否正确。如果不知道正确的权限设置，最稳妥的办法是改回默认的虚拟账户。
端口冲突是另一个容易被忽略的因素。默认实例使用 TCP 1433 端口，如果系统里已经跑了另一个 SQL Server 实例或者其他占用了 1433 端口的程序，安装程序会检测到端口被占用，服务启动失败。检查方法：命令行执行 netstat -ano | findstr :1433，如果看到 LISTENING 状态的进程，先确认它是什么程序。如果确实是端口冲突，可以在安装时给 SQL Server 指定其他端口，或者先停掉占用端口的进程。
还有一个非常奇葩的原因：系统时间异常。SQL Server 服务在启动时会校验证书有效性，如果系统时间和实际时间相差太大，证书校验失败，服务会启动不了。这类问题在测试环境的虚拟机上出现过一次，后来把时间同步打开就解决了。
2.3 安装到最后一步整体回滚
SQL Server 安装失败时会自动回滚，把已经安装的文件、注册表项全部撤销，让系统恢复到安装前的状态。回滚本身是一个保护机制，但对用户来说很痛苦，因为你不知道具体是哪个环节出了问题，一切又回到原点。
以我的经验，安装回滚的高发原因有三个：一是前面说的某个前置组件缺失，导致核心组件安装失败；二是安全软件实时扫描干扰了安装程序的写文件操作；三是系统存在残留的 SQL Server 注册表项或目录，安装程序在安装前检测到已有组件，后续操作出现冲突。
处理回滚问题最有效的方法是先看安装日志，而不是盲目重试。日志能告诉你真正失败的组件是哪个，再针对性处理，重装才有可能成功。重装前还要把环境清理干净，这个后面专门讲。
2.4 “需要重新启动计算机”无限循环
这个报错虽然不复杂，但在新版 Windows 上尤其常见。安装程序在检测到系统存在挂起的重启操作（PendingReboot）时，会直接终止安装并提示：
code复制需要重新启动计算机，然后才能继续安装 SQL Server。
你重启完再装，还是报同样的提示。原因是：安装程序写入注册表的重启标记没有被清除。很多软件安装完会在注册表里写入 PendingFileRenameOperations 这类标记，Windows 重启后这些标记应该被消耗掉，但有些情况（比如某个文件被占用）导致标记依然存在，安装程序就认为系统还没重启。
解决方法：手动检查注册表 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending 和 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations。如果确认系统已经重启过、确实没有其他软件需要完成安装，可以临时删除这些标记，然后重新运行安装程序。注意操作注册表前先备份，不要乱删。
3. 版本特有问题和升级隐患
SQL Server 各版本都有自己独特的脾气。很多人在网上搜答案时，发现同一个报错在不同版本上的处理方法完全不同，原因就在这里。
3.1 SQL Server 2008 R2 评估版到期的两种出路
SQL Server 2008 R2 虽然已经是老古董，但因为一些历史系统仍在运行，依然有不少人遇到它的问题。最常见的一个：安装时没注意用的评估版镜像，或者网上流传的企业版 ISO 实际上是评估版，装完只有 180 天试用期，到期后所有数据库引擎服务停止，报错类似：
code复制SQL Server 2008 R2 评估期已过。
处理办法有两条路线。如果你有正式版的产品密钥，最简单的方式是打开 SQL Server 安装中心 → 维护 → 版本升级，输入密钥完成版本升级。注意 SQL Server 2008 R2 对 sysadmin 权限要求比较高，升级必须在 sysadmin 账户下操作。
如果没有密钥，那只能考虑升级到新版本。SQL Server 2008 R2 已经停止官方支持，放到今天跑在生产环境风险很大。我在实际业务中遇到过不下五次，历史系统因为 2008 R2 过期导致服务停摆。建议尽快规划迁移，把数据库通过备份还原或者数据导入的方式迁到 2019 或 2022 上。
3.2 SQL Server 2019/2022 的操作系统硬性要求
新版 SQL Server 对操作系统版本的要求很明确。SQL Server 2019 支持 Windows Server 2016/2019、Windows 10 1809 以上；SQL Server 2022 支持 Windows Server 2016/2022、Windows 10 1607 以上。如果你在 Windows 7 或者更老的系统上硬装 2019，安装程序在“系统配置检查器”阶段就会直接打断你。
很多人忽略了另一个需求：PowerShell 版本。SQL Server 2019 和 2022 的安装程序依赖 PowerShell 3.0 以上版本。老旧系统里 PowerShell 版本太低，安装程序会静默失败或者在启动阶段卡住。我在装 SQL Server 2022 时遇到过一次，系统是 Windows Server 2016，PowerShell 5.1 其实是满足要求的，但之前有人把 PowerShell 降级过，导致安装程序直接无法启动。通过 Windows 更新把 PowerShell 恢复后，才正常安装。
硬件方面，SQL Server 2022 对内存的最低要求是 2GB，但我建议至少 4GB 才会比较流畅。磁盘空间：系统盘至少要有 6GB 可用，而且最好是 NTFS 格式。FAT32 格式的磁盘不支持文件权限控制，SQL Server 安装时会报权限错误。
3.3 sa 登录失败与 ODBC 驱动连接报错
这个报错严格来说不属于安装过程，但和安装后的配置密切相关：
code复制[28000] [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]用户 'sa' 登录失败。
如果你安装时选择的是“Windows 身份验证模式”，那么 sa 账号默认是被禁用的，所以每次用 sa 连接都会报 28000。解决方法有两个：一是用 Windows 身份验证模式登录 SSMS，在服务器属性 → 安全性里把“服务器身份验证”改为“SQL Server 和 Windows 身份验证模式”，然后在安全 → 登录名 → sa 的属性里设置密码并启用。二是如果你连 SSMS 都登不进去，那需要用命令行方式临时解决。
还有一类连接报错是驱动问题。比如：
code复制[DBNETLIB][ConnectionOpen (Connect()).]SQL Server 不存在或拒绝访问。
或者 Navicat、DBeaver 等工具连不上 SQL Server。这类问题基本集中在这几个点：SQL Server 服务没有启动；TCP/IP 协议未启用（在 SQL Server 配置管理器里确认）；防火墙未放行 1433 端口；SQL Browser 服务没启动（命名实例连接时尤其需要）。
有一点值得单独说：DBeaver 连接 SQL Server 时经常出现“Server closed the connection unexpectedly”之类的报错，这通常是驱动版本和 SQL Server 版本的兼容性问题，或者 TLS 版本协商失败。新版 SQL Server 默认启用 TLS 1.2，而老版本驱动只支持 TLS 1.0/1.1，配置一下连接字符串里的加密和 TLS 版本，往往能解决。
4. 安装日志是查出真相的唯一途径
我见过太多人在 SQL Server 安装失败后，不做任何分析就重试重装，运气好碰上一次成功，运气不好反复折腾一下午。真正专业并且高效的做法是：先看日志，再动手。
4.1 日志文件的位置和查看方法
SQL Server 安装日志集中在固定的目录里，核心日志路径是：
code复制C:\Program Files\Microsoft SQL Server\<版本号>\Setup Bootstrap\Log
这里 <版本号> 根据 SQL Server 版本不同：2008/2008 R2 是 100/110，2012 是 110，2014 是 120，2016 是 130，2017 是 140，2019 是 150，2022 是 160。注意有些按年份命名，有些按版本号命名。
在这个目录下，你首先看 Summary.txt。它会汇总本次安装的所有检查项和失败项，是最快定位问题的文件。如果 Summary 里面没有明确说明，再看当次安装时间戳文件夹里的 Detail.txt 或 ErrorLog。其中详细的错误信息通常在最后面几行，包含失败的功能名称和对应的错误码。
4.2 一个从日志定位真正问题的实际案例
有一次我在一台 Windows Server 2019 上安装 SQL Server 2019，安装到“安装程序支持文件”阶段就直接报错退出。SCC 全部通过，Temp 权限检查过，磁盘空间充足，杀毒软件也关了，问题照样出现。
最后通过看 Detail.txt，发现错误信息指向了一个叫做 SSCore 的组件，而该组件失败的原因是缺少 Microsoft Visual C++ 2015 Redistributable。但系统里明明已经装了 2017 版的运行库，为什么还会缺？看日志里的 GUID 后发现，SQL Server 2019 需要的是特定版本的 VC++ 运行库，2017 版提供的 DLL 版本号比它要求的低。解决办法是单独下载并安装 VC++ 2015-2022 Redistributable 的最新版，之后再运行安装程序，一路绿灯。
这个案例说明一个道理：日志不会骗人。报错提示让你摸不着头脑的时候，日志里的具体组件名和错误码才是唯一的线索。
4.3 命令行安装对排错的参考价值
除了图形界面安装，SQL Server 还支持命令行静默安装。命令大致形如：
bash复制setup.exe /q /ACTION=Install /FEATURES=SQLENGINE,SSMS /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS="BUILTIN\Administrators" /TCPENABLED=1 /SECURITYMODE=SQL /SAPWD="YourStrongPass" /IACCEPTSQLSERVERLICENSETERMS=true
我在排查顽固安装问题时，偶尔会用命令行安装。这不是为了追求无人值守，而是命令行安装的输出信息更直接。它会立即打印每个步骤的状态和失败原因，不会像图形界面那样隐藏细节。如果命令行安装成功了，说明环境没问题，之前图形界面失败大概率是交互过程中某个参数或临时状态触发的问题。
不过要强调：命令行安装适合有一定经验的人使用，新手不要一上来就折腾这个，优先在图形界面里排错。
5. 高频报错速查表与实战避坑心得
这一章把前面几章的要点浓缩成速查表，方便读者在实际操作中直接对照处理。然后再分享几个我在多次安装实战中形成的习惯，供大家参考。
5.1 SQL Server 安装高频报错速查表
| 报错关键字 | 常见原因 | 快速处理方案 |
|---|---|---|
| The required MSI package ... cannot be found | Temp 目录权限异常、空间不足、杀毒软件误删 | 清理并检查 %temp% 访问权限；预留 10GB 空间；暂时关闭安全软件 |
| 服务 'MSSQLSERVER' 启动失败 | 服务账户权限不足、1433 端口冲突、系统时间异常 | 服务管理器检查登录账户；netstat 检查 1433 端口；同步系统时间 |
| 安装到最后整体回滚 | 前置组件缺失、安全软件干扰、注册表残留 | 看日志确认失败组件，酌情补充 .NET/VC++ 运行库，清理残留后重装 |
| 重新启动计算机无限循环 | 注册表 PendingReboot 标记未被清除 | 检查并删除 PendingFileRenameOperations 等重启标记 |
| 评估期已过（2008 R2） | 使用评估版镜像安装 | 有密钥则做版本升级，无密钥则规划迁移到新版本 |
| sa 登录失败 [28000] | 服务器身份验证模式未切换、sa 被禁用 | 切换到混合模式，在 SSMS 中启用并设置 sa 密码 |
| ODBC 连接报错 / connection unexpectedly | 服务未启动、TCP/IP 未启用、TLS 版本不匹配 | 检查 SQL Server 配置管理器、防火墙 1433 端口、更新驱动 |
| DISM 安装报错 740 | 操作需要更高权限，当前进程未提权 | 以管理员身份运行命令行 |
5.2 卸载重装的正确姿势与两个私人习惯
如果安装反复失败，最坏情况下需要卸载并重装 SQL Server。卸载时直接进控制面板卸掉主服务还不够，残留的注册表项和目录会导致下次安装时出现莫名其妙的问题。
我自己的清理流程是：控制面板卸载 → 重启 → 删除 C:\Program Files\Microsoft SQL Server 残留目录 → 删除 C:\ProgramData\Microsoft SQL Server（如果存在）→ 打开注册表编辑器，删除 HKLM\SOFTWARE\Microsoft\Microsoft SQL Server 相关残留项 → 清理服务列表里的残留服务 → 再重启，重新安装。这套流程我执行了很多次，基本能保证干净的环境。
两个个人习惯，供参考：一是安装前一定先运行一次 Windows Update，把系统补丁和 .NET Framework 都更新到最新，很多安装问题本质是系统组件太旧；二是下载安装包时认准微软官网链接源，不和别人共享来历不明的 ISO。宁可多花几分钟下载，也不要在安装阶段耗费几个小时排查。
还有一个心得：SQL Server 安装报错往往不是单点问题，而是多个因素叠加的结果。遇到报错先别急着重试，按“前置检查 → 日志定位 → 针对处理”的顺序排查，多数问题都能快速解决。