SQL Server 2012安装全流程：前置决策、关键配置与远程排错

SQL Server 2012 安装这件事，说难不难，说简单也真不简单。我这些年帮人处理过的安装问题，最后归结起来八成都不是“下一步”点错了，而是装之前根本没想清楚要什么：装哪个版本、用默认实例还是命名实例、认证模式选哪种、排序规则定了没。这些问题在安装向导里都是几秒钟的事，但一旦选错，后面拆库重建的代价可能就是好几天。所以这篇文章不打算只给你一份“下一步—下一步—完成”的截图流水账，我想把 SQL Server 2012 安装这件事完整拆开：从最开始的版本决策，到环境依赖的坑，到向导里每个页面到底在问你什么，再到装完连不上、远程访问不通怎么一个个排查。不管你是第一次在自己机器上装数据库练手，还是要在内网服务器上给一个老系统补齐运行环境，这套流程和思路都能直接拿去用。内容会偏实操，参数、命令、注册表路径、报错原文我都会写清楚，方便你对照着干活。

1. 动手之前先想清楚：三个决定成败的前置决策

安装向导只花二十分钟，但前面这三个决策会影响这套数据库未来几年的运维成本。我见过太多人抱着“先装起来再说”的心态点下一步，结果半年后发现默认实例和测试实例撞名、排序规则和业务库对不上、sa 账户密码谁也不知道。这几件事在安装阶段都是一次性选择，事后修改的成本远高于当时多想五分钟。

1.1 版本选型：不是越贵越好，而是功能对齐

SQL Server 2012 的版本线比较长，从免费的 Express 到企业版，功能差异非常实际。选型的原则只有一条：看你的业务真正会用到哪些功能，而不是看哪个名字听着厉害。

我碰到过一个挺典型的场景：某公司内部的一个数据采集系统，用 Express 版本跑了两年，数据量涨到 8 GB 之后开始各种报错，最后发现是撞了 10 GB 的单库上限。这个坑其实在选型阶段就能看出来——只要你的业务有长期累积的日志表、流水表，基本可以断定三年内会突破 10 GB，那就别在 Express 上纠结了。

还有一个更隐蔽的坑：Express 版本没有 SQL Server 代理服务。很多人装完之后想建个定时清理作业，翻遍管理界面找不到“作业”节点，还以为是安装出问题了。这不是 bug，是版本能力差异。如果你的方案里包含任何“每天凌晨自动跑一次”的需求，Express 直接排除。

1.2 默认实例还是命名实例：一次装错，后面全是麻烦

这个问题经常被忽略，因为安装向导里它只是一个小页面。但它的影响非常直接：一台机器上只能有一个默认实例，默认实例的监听端口是 1433，连接时不需要写实例名；命名实例可以装多个，用动态端口或指定端口，连接时必须写成主机名\实例名的形式。

我的经验判断标准是这样的：如果这台机器只打算跑一套数据库，并且是给业务系统正式用的，那就用默认实例，连接串简单，运维心里也清楚。如果这台机器上已经有数据库了，或者你打算在一个测试环境里并存多个版本、多套环境（比如开发库和测试库隔离），那一律用命名实例，比如DEV2012、TEST2012这种一眼能看懂的命名。

有个细节一定要提醒：命名实例默认会使用动态端口，也就是说每次服务重启端口可能变，这在防火墙严格的环境里会莫名其妙连不上。安装时或者装完之后，一定要去配置管理器里把它固定成静态端口，比如 51433，并且把 SQL Server Browser 服务设置成自动启动，否则客户端连命名实例时找不到端口。

还有一点，实例名一旦定下来，改起来需要卸载重装。所以在点“下一步”之前，把命名规范跟团队确认好，别用SQLEXPRESS这种默认名糊弄过去，半年后没人记得这台机器上哪个实例对应哪个项目。

1.3 身份验证模式与账户规划：安全与便利的取舍

安装向导里那个“数据库引擎配置”页面，会让你在 Windows 身份验证模式和混合模式之间二选一。这个选择的本质是：你允不允许应用通过用户名密码连数据库。

纯 Windows 身份验证更安全，密码策略交给操作系统管，DBA 不用记一堆应用账号密码。但它有个硬性前提：应用服务器和数据库服务器必须在同一个域里，或者至少有信任关系。很多小型项目根本没有域环境，应用跑在另一台独立的工作组机器上，这时候纯 Windows 认证就走不通了。

混合模式是更常见的实际选择，它同时保留 Windows 登录和 SQL 登录两条路径。选混合模式时，向导会强制你设置 sa 账户密码，并且会做复杂度校验——长度不够或者全是字母数字组合，它会直接拦住你。

这里分享一个我一直在用的做法：安装时设一个足够复杂的 sa 密码并记在密码管理工具里，装完之后立刻把 sa 账户禁用，业务应用各自建独立的登录名，按库授权。这样既保留了混合模式的灵活性（需要时可以临时启用 sa 救急），又不会让一个超级账户长期暴露在外。sa 常年启用并且密码是123456的数据库，我在内网里见过不止一次，这种配置一旦被人摸到入口，整个实例就是别人的了。

1.4 排序规则：装之前不定，装之后流泪

排序规则决定了数据库怎么比较字符串、怎么排序、大小写敏不敏感、重音敏不敏感。它藏在安装向导的“排序规则”标签页里，默认值通常跟着操作系统语言走，很多人压根没打开看过。

安装程序在中文系统上给出的默认值一般是类似Chinese_PRC_CI_AS的形式，拆开看：CI表示 Case Insensitive（不区分大小写），AS表示 Accent Sensitive（区分重音）。对于绝大多数国内业务系统，这个默认值是可以直接用的。

但有两类场景必须提前确认：一是从旧系统迁移，老库用的排序规则如果和新实例不一致，迁移时字符串字段的排序、去重、JOIN 结果都可能变化；二是跨库查询，两个排序规则不同的库做 JOIN 时，会直接抛出“无法解决 equal to 操作的排序规则冲突”的错误，解决方式是加COLLATE强制转换，但那会让索引失效，性能掉得很厉害。

需要改排序规则，只能在安装阶段改，或者装完之后重建整个实例。所以我的建议很直接：安装前问一句“这套库以后要不要跟别的库做跨库查询”，如果有，就统一成同一套排序规则；如果是从老系统迁移，就把老库的排序规则查出来（SELECT SERVERPROPERTY('Collation')），照着装。

2. 环境准备：那些“看起来无关”却最容易卡住安装的依赖

安装向导的规则检查页面会列出一长串检查项，绝大多数人都是看到一片绿勾才放心点下一步。但我可以负责任地说，初次安装失败的原因里，超过一半出在这个页面上。这一节把几个高频依赖项拆开讲，包括它们的原理和绕过的正确姿势。

2.1 系统版本与硬件门槛：别拿家用系统硬上

SQL Server 2012 对操作系统的要求不算苛刻，但也不是随便什么系统都能装。它支持的客户端系统从 Windows 7 SP1 起步，服务器系统从 Windows Server 2008 R2 SP1 起步。注意这里的关键词是SP1，没有打补丁的 Windows 7 或者 Windows Server 2008 R2，规则检查会直接拦住你，提示操作系统版本不满足最低要求。

硬件方面，官方给出的最低配置是 1.4 GHz 处理器、512 MB 内存（Express）或 1 GB 内存（其他版本）、6 GB 可用磁盘空间。但这些都是“能装进去”的门槛，不是“能用”的门槛。

我给的实际建议配置是：

• 内存：开发机 4 GB 起步，服务器 8 GB 起步。SQL Server 的内存管理策略是“有就多用”，内存不足时会频繁读写磁盘，表现为查询突然变慢。
• 磁盘：系统盘之外单独留一块数据盘，安装目录、数据文件、日志文件分开放。安装本身占 6 GB 左右，但临时文件、错误日志、后续的数据库增长都需要空间，我一般会预留 50 GB 以上。
• 处理器：至少双核。单核机器上装数据库，随便一个稍微复杂的查询就能把 CPU 打满，体验很差。

还有一个容易被忽略的点：磁盘文件系统必须是 NTFS。如果你的数据盘是 FAT32 格式，规则检查会给出一条警告，虽然不会阻止安装，但后续数据库文件超过 4 GB 时会出问题（FAT32 的单文件上限）。现在这种情况很少见了，但如果用的是移动硬盘或者二手服务器，值得看一眼。

2.2 .NET Framework 3.5：安装过程中最常见的“拦路虎”

这一项必须单独拿出来说，因为它在 Windows 8 和 Windows Server 2012 上的表现特别容易让人懵。

SQL Server 2012 的安装程序依赖 .NET Framework 3.5 SP1，注意是3.5，不是 4.0，也不是 4.5。而 Windows 8 / Windows Server 2012 这些系统出厂自带的是 4.5，3.5 是作为“可选功能”存在、默认不安装的。

在 Windows Server 2008 R2 及更早的系统上，安装程序会自动帮你下载并安装 3.5，过程比较顺。但在 Windows 8 / Server 2012 上，情况变了：安装程序发现缺少 3.5，会弹出提示让你“安装此功能”，点确定之后它会尝试从 Windows Update 拉取。如果这台机器不能上外网，或者组策略禁用了 Windows Update，这个过程会卡住或者直接失败，然后安装就进行不下去了。

正确的做法有两种，我一般用第一种：

第一种，提前手动启用功能。打开“服务器管理器”，进入“添加角色和功能”，一路下一步到“功能”页面，勾选“.NET Framework 3.5 功能”，然后指定一个安装源。这个安装源需要是系统安装镜像里的sources\sxs目录。用命令行的方式更直观：

# 挂载系统安装镜像到 D 盘后执行 Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 -Source D:\sources\sxs -All

如果是命令行工具dism，写法是：

dism /online /enable-feature /featurename:NetFx3 /All /Source:D:\sources\sxs /LimitAccess

/LimitAccess这个参数的意思是“不要去找 Windows Update”，强制只从本地源取文件，在离线环境里这个参数是必须的，不加的话它还是会先去联网尝试，然后超时报错。

第二种，让安装程序自己处理。前提是这台机器能正常访问外网，并且组策略没有拦截 Windows Update。这种方式省事但不可控，我一般只在临时测试机上这么干。

还有一个判断技巧：如果你不确定 3.5 到底装没装，可以在 PowerShell 里跑一句Get-WindowsFeature Net-Framework-Core（服务器系统）或者看注册表HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5下面的Install值是不是 1。花十秒钟确认一下，比装到一半被拦住强。

2.3 权限、UAC 与安装介质的处理

安装 SQL Server 需要本地管理员权限，这一点没什么可商量的。但“是管理员”和“以管理员身份运行”是两回事，特别是在开了 UAC 的机器上。

我遇到过好几次这样的情况：用户明明是管理员组的成员，双击setup.exe之后安装到一半报权限错误。原因就是 UAC 把进程的实际权限降级了。解决办法很土但很有效：右键setup.exe，选择“以管理员身份运行”。或者干脆关掉 UAC 重启后再装（不推荐，装完记得开回来）。

安装介质方面，推荐把 ISO 挂载成虚拟光驱，或者解压到本地硬盘的一个纯英文路径下，比如D:\SQL2012\。避免两种做法：一是直接在压缩包里双击运行，二是把安装文件放在中文路径或者带空格的路径下。前者会因为临时解压目录的权限问题失败，后者在某些组件注册时会出问题。

另外提醒一下，安装前最好把杀毒软件的实时监控临时关掉。安装过程会写入大量文件、注册大量组件，某些杀软的启发式扫描会误判并拦截，表现为安装卡在某一步不动，或者某个服务注册失败。装完再打开就行。我自己就吃过一次亏，装了三次都在同一个位置回滚，最后发现是杀软把某个 DLL 隔离了。

3. 安装过程逐步拆解：从挂载镜像到实例跑起来

环境准备好了，接下来就是向导操作。这一节我把每个关键页面在问什么、该怎么答、为什么这么答，逐页拆开。你照着走，基本不会出岔子。

3.1 安装中心与规则检查：先看红叉，再看黄叹号

运行setup.exe之后，首先出现的是“SQL Server 安装中心”。这个界面有几个选项：全新安装、从介质安装（主要是给其他机器部署用的）、系统配置检查器、安装管理工具等。

先别急着点“全新安装”，我建议先点“系统配置检查器”跑一遍。它会把所有前置条件过一遍，红色叉号是必须解决的阻塞项，黄色叹号是警告项。花两分钟看清楚，比装到一半回滚效率高得多。

点进“全新安装”之后，产品密钥页面、许可条款页面都比较直白。产品密钥页面如果是 Express 版本，会自动带出来，不用填。许可条款页面记得勾选“我接受”。

接下来是“安装程序支持规则”页面，这是真正的第一道关卡。常见的红叉有这么几种：

• “重新启动计算机”挂起检查失败。意思是系统里有未完成的挂起操作，通常是上次安装软件或者打补丁后没重启。解决方式就是老老实实重启一次。如果重启之后还是报这个，说明有残留的挂起标记，需要清理注册表里的PendingFileRenameOperations（位于HKLM\SYSTEM\CurrentControlSet\Control\Session Manager）或者HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending这个键。
• 性能计数器注册表项一致性检查失败。这个下面专门讲，是个高频问题。
• 旧版本 SQL Server 组件残留。机器上装过 2005 或者 2008 的某些组件，卸载不干净。这种情况要么彻底清理，要么忽略警告继续（通常不影响 2012 的安装）。

3.2 功能选择：按需勾选，别一股脑全选

“功能选择”页面会列出所有可安装的组件：数据库引擎服务、SQL Server 复制、全文搜索、Analysis Services、Reporting Services、数据质量服务、客户端工具、管理工具等等。

全选看起来很省事，但会带来几个实际问题：占用空间大（全选 6 GB 以上）、安装时间长、组件多导致出问题的概率上升。更关键的是，某些组件需要额外配置，比如 Reporting Services 装完之后还要配置报表服务器，如果你根本不用它，这部分配置工作就是白费。

我的勾选原则是这样：

• 数据库引擎服务：必选，这是核心。下面的“SQL Server 复制”和“全文搜索”按需勾选。复制用于多库同步，全文搜索用于大文本模糊检索，用不到就不勾。
• 客户端工具向后兼容性 / SDK：如果你需要用旧版工具连接（比如老项目用 SQL Server 2008 的管理工具连 2012），就勾上。纯新项目可以不勾。
• 管理工具 - 基本 / 完整：必选。这里有个大坑——SQL Server 2012 的管理工具（SSMS）是独立安装项，不在主安装流程里。也就是说，你把数据库引擎装完了，桌面上不会有管理界面。必须在安装中心里单独点“安装 SQL Server 管理工具”，或者在这里勾上“管理工具 - 完整”。

我见过不止一个人装完之后对着空荡荡的开始菜单发呆，以为自己装失败了。其实数据库引擎早就跑起来了，只是缺个图形界面。这也是为什么我建议在功能选择页面就把管理工具勾上，一步到位。

3.3 实例配置与服务账户：这里有三个细节要留意

“实例配置”页面会让你选择默认实例或命名实例，如果选命名实例要填名字。前面已经讨论过怎么选，这里说三个技术细节。

第一，实例目录。页面下方会显示实例根目录，默认是C:\Program Files\Microsoft SQL Server\。如果系统盘空间紧张，可以改到数据盘。注意这个目录不要放在路径里有中文或者特殊字符的位置。

第二，实例 ID。默认实例的实例 ID 是MSSQLSERVER，命名实例的 ID 是你填的实例名。这个 ID 会决定服务名（MSSQLSERVER或MSSQL$实例名）和注册表路径，基本上定了就改不了。

第三，服务账户。接下来的“服务器配置”页面会要求给每个服务指定运行账户和启动类型。SQL Server 数据库引擎服务、SQL Server 代理、全文搜索等服务各占一行。

关于账户选择，有三种常见做法：

我个人的默认选择是虚拟账户，从 2008 R2 开始就支持了，权限控制得最干净，也不用担心密码过期导致服务起不来。如果你选了域账户，一定要在域控上给它配好“作为服务登录”的权限，否则安装到最后一步服务启动会失败。

启动类型方面，数据库引擎服务设为“自动”，SQL Server 代理也设为“自动”（如果你要用定时作业）。其他服务如果暂时不用，可以设成“手动”，减少开机资源占用。

3.4 数据库引擎配置与排序规则：这一步定终身

“数据库引擎配置”页面有三个标签：安全模式、服务账户（前面配过）、排序规则。

安全模式标签就是前面讨论的身份验证模式选择。选混合模式时填 sa 密码，密码要满足复杂度要求——至少 8 位，包含大小写字母、数字、符号中的三类。填完之后可以点“添加当前用户”把当前登录账户加为管理员，这样装完之后至少有一个能进去的入口。

排序规则标签里，点“自定义”可以看到完整的排序规则列表。中文环境常用的几项：

选哪个，前面 1.4 节已经说过判断方法。这里补一句：如果这台实例以后要跟其他实例做链接服务器查询，排序规则最好保持一致，否则跨实例 JOIN 时会遇到前面说的排序规则冲突错误。

3.5 安装完成之后，必须马上做的四件事

进度条走完，弹出“安装成功”，很多人到这里就收工了。但我建议装完之后立刻花十分钟做下面四件事，能省掉后面很多麻烦。

第一件，检查服务状态。打开“服务”管理器，确认SQL Server (MSSQLSERVER)或对应的命名实例服务处于“正在运行”。如果显示“已停止”，手动启动一下，看事件查看器里有没有报错。常见原因是服务账户权限不足或者端口被占用。

第二件，装管理工具。如果安装时没勾管理工具，现在去安装中心补装。装完之后用 Windows 身份验证连上去，确认能正常登录。

第三件，打补丁。SQL Server 2012 的初始版本（RTM）有不少已知问题，官方后续发布了 SP1 到 SP4 多个服务包。装完 RTM 之后应该立刻安装最新的服务包，这个顺序不能反——先装 RTM 再打补丁，而不是直接拿集成补丁的介质装（虽然集成介质也可以，但补丁级别要确认清楚）。判断当前补丁级别可以用：

SELECT SERVERPROPERTY('ProductVersion') AS 版本号, SERVERPROPERTY('ProductLevel') AS 补丁级别, SERVERPROPERTY('Edition') AS 版本类型;

ProductLevel显示RTM就是初始版，SP4就是打了第四个服务包。

第四件，设置最大服务器内存。这个特别重要，尤其是数据库和别的服务混部在同一台机器上时。SQL Server 默认会尽可能多地占用内存，如果不设上限，可能把操作系统和同机其他应用的内存吃光，整台机器卡死。

设置方式是在管理工具里右键实例 → 属性 → 内存，把“最大服务器内存”设成一个合理值。经验公式是：留 4 GB 给操作系统，剩下的分配给数据库。比如 16 GB 内存的服务器，最大服务器内存设 12 GB 左右。如果是专用数据库服务器，可以留 2 GB 给系统，其余全给数据库。

4. 远程连不上？按这个顺序排查最省时间

装完能本机连上，不代表别的机器能连上。远程连接不通是安装之后最高频的问题，而且报错信息往往很含糊，比如“在与 SQL Server 建立连接时出现与网络相关的或特定于实例的错误”，这句话基本等于没说。我一般按下面这个顺序排查，基本能在十分钟内定位。

4.1 协议、端口、服务：三个开关缺一不可

远程连接依赖三个条件同时满足，缺任何一个都不通。

条件一，TCP/IP 协议已启用。SQL Server 2012 的 Express 版本默认关闭 TCP/IP 协议，只用共享内存和命名管道，这两个协议只支持本机连接。启用方式：打开“SQL Server 配置管理器”→ 展开“SQL Server 网络配置”→ 点“MSSQLSERVER 的协议”（命名实例对应你自己的实例名）→ 右键“TCP/IP”→ 启用。

条件二，端口固定下来了。启用 TCP/IP 之后，双击它进入属性，切到“IP 地址”标签，拉到底部的“IPAll”区域。这里有两个值：TCP 动态端口和TCP 端口。正确的做法是清空动态端口，在 TCP 端口里填一个固定值，默认实例填 1433，命名实例建议填一个不冲突的端口比如 51433。填完之后重启 SQL Server 服务才生效。

为什么必须固定端口？因为动态端口每次服务重启都可能变，防火墙规则没法跟着变，客户端连接也会时好时坏。

条件三，SQL Server Browser 服务在跑。如果你用的是命名实例，客户端连接时只给了主机名没给端口，那就需要 Browser 服务来告诉客户端“这个实例在哪个端口”。这个服务的默认启动类型是“手动”甚至“禁用”，必须改成“自动”并启动。

这三个条件都满足之后，本机用telnet 127.0.0.1 1433或者 PowerShell 的Test-NetConnection -ComputerName 127.0.0.1 -Port 1433测一下，通了再往下走。

4.2 防火墙：入站规则要自己加

Windows 防火墙默认不放行 1433 端口。安装程序其实会自动创建几条入站规则，但有时候因为各种原因没创建成功，或者规则被组策略覆盖了，所以手动确认一遍比较稳妥。

打开“高级安全 Windows 防火墙”→ 入站规则 → 新建规则 → 端口 → TCP → 特定本地端口填 1433（或你的自定义端口）→ 允许连接 → 配置文件全勾 → 命名成好记的名字比如“SQL Server 1433”。

命名实例还需要额外放行 SQL Server Browser 的 UDP 1434 端口，否则客户端连命名实例时找不到端口信息。

如果机器上装了第三方安全软件，也要在它的防火墙里放行对应端口，这一步经常被忽略，因为 Windows 防火墙看着是通的，但流量被第三方软件拦在外面。

4.3 登录名、连接串与报错对照表

网络层通了之后，还有可能卡在认证层。几种典型报错和对应原因：

连接串的写法也容易出错。默认实例的服务器名就是主机名或者 IP，比如192.168.1.10；命名实例必须写成192.168.1.10\DEV2012，中间是反斜杠。如果用非默认端口，还要加端口号，格式是192.168.1.10,51433，注意是逗号不是冒号，这个细节很多人写错。

还有一点，实例属性里的“连接”页面要勾选“允许远程连接到此服务器”。这个选项默认是勾上的，但如果之前被人关掉过，就会出现本机能连、远程死活连不上的情况，排查时容易漏掉。

5. 静默安装：一条命令批量部署的正确姿势

如果你只有一台机器要装，图形向导足够了。但如果你要给测试环境批量部署几台、或者需要把安装过程写成自动化脚本，那就得用命令行的静默安装。这一节把参数拆开讲清楚。

5.1 核心参数逐项解释

静默安装的基本命令长这样：

setup.exe /Q /ACTION=Install /FEATURES=SQLEngine /INSTANCENAME=MSSQLSERVER ^ /SQLSVCACCOUNT="NT Service\MSSQLSERVER" /SQLSVCSTARTUPTYPE=Automatic ^ /SQLSYSADMINACCOUNTS="BUILTIN\Administrators" ^ /AGTSVCACCOUNT="NT Service\SQLSERVERAGENT" /AGTSVCSTARTUPTYPE=Automatic ^ /SECURITYMODE=SQL /SAPWD="YourStrongPwd!2012" ^ /TCPENABLED=1 /NPENABLED=1 /IACCEPTSQLSERVERLICENSETERMS

几个参数值得单独说：

• /Q表示完全静默，不弹任何界面。调试阶段建议先换成/QS（带进度条但不需交互），出问题时能看到卡在哪一步。
• /FEATURES=SQLEngine只装数据库引擎。要装管理工具的话写成SQLEngine,SSMS,ADV_SSMS，注意ADV_SSMS是完整版管理工具。
• /SQLSYSADMINACCOUNTS指定哪些账户成为实例的系统管理员。这里填的是 Windows 账户，多个账户用空格分隔并整体用引号包起来。如果填错，装完之后你会发现自己进不去。
• /SECURITYMODE=SQL对应混合认证模式，必须配合/SAPWD使用。如果只要 Windows 认证，就写/SECURITYMODE=Windows并去掉密码参数。
• /TCPENABLED=1在安装阶段就把 TCP/IP 协议打开，省得装完还要去配置管理器手动开。
• /IACCEPTSQLSERVERLICENSETERMS是接受许可条款的声明，不加这个参数静默安装会直接退出。

命令里的^是 Windows 命令行的续行符，如果你把命令写成一行就不需要它。在 PowerShell 里续行符是反引号。

5.2 用配置文件复用安装参数

纯手敲参数容易出错，更稳妥的方式是先用图形向导走一遍，在最后“准备安装”页面会显示一个“配置文件路径”，通常在：

C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\Log\<时间戳>\ConfigurationFile.ini

这个 ini 文件里记录了刚才所有页面的选择，包括产品密钥、实例名、排序规则、目录路径、服务账户等。把它复制出来，改掉路径和账户相关的内容，然后这样调用：

setup.exe /ConfigurationFile="D:\deploy\sql2012_config.ini" /Q

这种方式的好处是参数全部可视化确认过一遍，不会漏项；缺点是文件里包含产品密钥和 sa 密码明文，一定要放在受控的目录里，用完删掉或者加密保管。

批量部署时我一般会准备两份配置文件：一份是开发测试环境用的（Express 或 Standard，命名实例，简单密码），一份是正式环境用的（Standard 或 Enterprise，默认实例，强密码，指定排序规则）。两份分开管理，避免把测试配置误推到生产。

6. 踩坑实录：几个高频问题的真实排查过程

这一节写几个我自己实际遇到过、也在别人机器上复现过的问题。每个问题都给出报错现象、原因判断和解决步骤，方便你对照。

6.1 性能计数器注册表项一致性检查失败

这是安装规则检查页面最常见的红叉之一，提示大意是“性能计数器注册表项一致性检查失败”，英文环境下的原文是The performance counter registry hive consistency check failed。

安装程序需要读取系统的性能计数器来监控安装过程，当注册表里的性能计数器列表和实际的计数器文件不一致时，这项检查就挂了。常见诱因是装过某些监控软件、或者卸载过其他数据库产品，把计数器搞乱了。

解决方式是重建性能计数器。注意要分别对 32 位和 64 位两个位置执行，很多人只跑了一次，问题没解决：

# 64 位位置 C:\Windows\System32\lodctr.exe /R # 32 位位置（64 位系统上才有这个目录） C:\Windows\SysWOW64\lodctr.exe /R

执行完会刷一屏“正在重建计数器”，然后重新跑安装程序，检查应该就过了。

如果还不行，说明某个具体的计数器服务有问题，需要看Event Viewer里Application日志的详细报错，定位到具体是哪个计数器文件损坏，再从正常机器上拷贝对应的.ini文件过来。

有一种“绕过”的做法是直接关掉这项检查（修改注册表里的Disable Performance Counters值），但我非常不建议——性能计数器坏了不仅是安装问题，后续你用性能监视器看数据库指标也会是空的，等于自断一条排查路径。

6.2 安装到一半突然回滚

现象是进度条走到某个百分比停住，然后弹窗“安装失败”，接着开始回滚，最后提示“SQL Server 安装失败，因为无法启动服务”。

这种问题的排查入口只有一个：安装日志。路径在：

C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\Log\

每次安装都会生成一个带时间戳的目录，里面有Summary.txt（汇总，先看这个）和一堆Detail.txt、Detail_GlobalRules.txt。Summary.txt里会列出哪些组件成功、哪些失败，失败的组件后面跟着错误码。

我遇到过几次的典型原因：

原因一，端口冲突。1433 端口已经被别的程序占用（比如另一套数据库、或者某些开发工具的本地服务）。解决办法是先netstat -ano | findstr :1433看是哪个进程占着，要么停掉它，要么给新实例换个端口。

原因二，服务账户权限不足。用了域账户但没给“作为服务登录”权限，或者账户密码输错了。这种情况Summary.txt里会明确写“无法启动服务”，事件查看器里会有“登录失败”的记录。

原因三，目录权限问题。数据目录或者日志目录放在了网络共享上，或者路径里有特殊字符。SQL Server 的数据文件必须放在本地磁盘，网络路径不支持（除非用特定的共享存储方案）。

原因四，杀毒软件拦截。前面提过，安装过程中某个 DLL 被隔离，导致组件注册失败。关掉实时扫描重装一次，基本能确认是不是这个原因。

回滚之后不要急着重装，先花十分钟把Summary.txt从头到尾读一遍，绝大多数时候答案就在里面。

6.3 服务启动失败：事件查看器比报错弹窗有用十倍

安装过程一切正常，但装完服务起不来，或者过几天莫名其妙停了。这种问题光看安装程序的提示没用，必须去事件查看器。

打开“事件查看器”→ Windows 日志 → 应用程序，筛选来源为MSSQLSERVER或者SQLSERVERAGENT的事件。常见的几类错误：

还有一个比较隐蔽的情况：服务能启动，但过一会儿自动停了。这种情况十有八九是服务账户的登录密码在域策略里过期了，或者账户被锁了。用域账户跑数据库服务时，一定要把密码过期策略单独处理，不然某个周一早上数据库集体挂掉，排查半天才发现是密码问题。

6.4 装完之后发现排序规则选错了

这个不算“报错”，但破坏力不小。典型表现是：两个库做 JOIN 时报排序规则冲突，或者查询结果里中文字符的排序顺序跟预期不一样。

如果数据库里还没有业务数据，最简单的方式是卸载重装，改排序规则。虽然麻烦，但比后面带着问题跑要干净。

如果已经有数据了，那就只能走“导出—重建—导入”的路子：

-- 1. 先查清楚当前实例和各个库的排序规则 SELECT name, collation_name FROM sys.databases; -- 2. 建一个新库，指定正确的排序规则 CREATE DATABASE NewDB COLLATE Chinese_PRC_CI_AS; -- 3. 用导入导出工具或者脚本把数据迁过去 -- 4. 应用连接串切到新库，验证通过后下线老库

需要提醒的是，表级别的排序规则可以单独指定（建表时写COLLATE），所以理论上有一种“局部修正”的方案：只把出问题的字段或表改成正确排序规则。但这会带来不一致性，后续维护的人容易踩坑，我一般不建议在生产库上这么干。

6.5 一套完整的自检清单

最后给你一份装完之后的自检清单，照着过一遍，基本能保证这套实例是健康的：

还有一个小建议：装完测试没问题之后，把这次安装用的配置文件、补丁包、排查用到的命令都整理到一个文档里，跟实例信息一起归档。半年后别人接手这台机器，或者你要重装的时候，这份文档能省下大量时间。我自己维护的每一套数据库实例都有这么一份“装机记录”，里面连端口号、排序规则、服务账户类型都写清楚，看起来啰嗦，实际上救过我好几次。