1. 装之前先把版本和硬件底线捋清楚装 SQL Server 2012 这件事说难不难说简单也容易翻车。我在物理机、VMware 虚拟机、云主机上前后装过二十来遍最顺的一次从双击 setup.exe 到能跑通查询只花了十几分钟最折腾的一次卡在性能计数器一致性那条规则上耗掉整整一个下午。这篇安装步骤详解就是把这二十来遍的经验压成一条尽量不绕弯的路把每一步为什么这么选讲透。先说清楚这篇内容适合谁一是做课程设计、毕业设计需要在本地起一个能连能用的实例二是接手老系统要复现一个 SQL Server 2012 环境做兼容性验证三是第一次面对 SQL Server 安装向导被一堆规则检查和功能树弄得不知道该勾哪个的新手。核心就三件事——数据库、SQL Server 2012、安装步骤后面所有内容都围绕这三件事展开不讲虚的。1.1 课程设计、测试、生产三种场景对应三种版本SQL Server 2012 的版本谱系比很多人想象的复杂Enterprise企业版、Business Intelligence商业智能版、Standard标准版、Web 版、Developer开发版、Express简易版。很多人第一反应是装企业版最保险这个思路在课程设计阶段其实是个坑因为企业版的功能树会多出大量平时根本用不到的服务安装时间和后续维护成本都上去了。选版本的正确姿势是从用途反推。做数据库课程设计、毕业设计、个人练手Developer 版是最优解——它的功能集和企业版完全一致包括分区表、AlwaysOn、数据压缩这些高级特性唯一限制是授权只允许用于开发和测试不允许上生产。你拿它跑课设、跑实验、跑性能测试一点问题都没有。如果是给一个小团队内部用的实际业务系统Standard 版足够覆盖绝大多数场景它对 CPU 插槽数和内存有上限但对中小型业务完全够用。Express 版适合做嵌入式或者学习入门数据库单库上限 10GB内存最大用 1GB连个稍大点的数据集就开始吃力我一般只在需要快速给学员发一个免安装式练习环境时才用它。还有一点常被忽略SQL Server 2012 是 2012 年发布的它的官方生命周期早已结束最后一个服务包是 SP4。这意味着如果你打算把它用在实际业务上安全补丁的获取需要谨慎评估但在离线实验环境、内网培训环境、老系统兼容验证环境里它依然是个稳定的选择。我的建议是学习和测试随便装生产环境请评估替代方案。版本适用场景主要限制我的推荐度Developer课程设计、开发测试不可用于生产强烈推荐Standard中小型业务系统CPU/内存有上限推荐Enterprise大型业务、高可用成本高、安装重视需求Express入门学习、嵌入式单库 10GB、内存 1GB入门可用1.2 硬件与操作系统的实际底线含参数表官方文档给的最低配置看起来非常宽松x64 处理器 1.0 GHz 以上1GB 内存6GB 磁盘空间。但按这个底线装出来的实例你打开 Management Studio 连上去点两下就会开始怀疑人生。这是我踩过的第一个坑——当年在 2GB 内存的虚拟机上装完恢复一个几百兆的备份文件花了快四十分钟。我的实际经验值是这样的处理器双核 2.0 GHz 起步内存 4GB 是舒适线8GB 以上才能同时跑数据库和开发工具不卡顿。磁盘方面程序文件加系统数据库master、model、msdb、tempdb装完大概占 4 到 8GB但你至少要留出 20GB 以上的空闲空间因为 tempdb 会随查询规模膨胀日志文件也会长。磁盘类型这一项很多人不在意但差距巨大。机械硬盘上装 SQL Server光是启动服务就要几十秒换成 SSD 之后同样的实例启动通常在三秒内完成恢复备份的速度能差好几倍。如果你在用虚拟机务必把虚拟磁盘放在 SSD 上并且优先选固定大小而不是动态扩展动态扩展盘在数据库写入场景下会频繁触发扩容性能抖动非常明显。操作系统这一项需要单独提醒。SQL Server 2012 原生支持的是 Windows 7 SP1、Windows Server 2008 R2 SP1、Windows 8 / 8.1、Windows Server 2012 / 2012 R2 这一代系统。如果你在 Windows 10 或 Windows 11 上安装会遇到两个典型问题一是 .NET Framework 3.5 默认没启用安装程序会直接报依赖缺失二是部分规则检查项会因为系统版本超出预期范围而失败。这不是不能装而是需要额外处理后面第 4 章我会专门讲怎么过这两关。项目官方最低我的建议值说明CPU1.0 GHz x64双核 2.0 GHz影响查询并发能力内存1GB4GB 起8GB 舒适低于 4GB 恢复备份很慢磁盘空间6GB预留 20GBtempdb 和日志会增长磁盘类型无要求SSD启动和恢复速度差距巨大操作系统Win7 SP1 / Server 2008 R2 SP1同代系统最稳新版系统需额外处理1.3 安装介质与前置依赖的核对清单安装介质这块最常见的翻车方式是拿着一个来路不明的 ISO 直接挂载运行结果卡在提取文件失败或者安装到一半报安装程序文件损坏。我的做法固定是三步先校验文件哈希再解压到本地硬盘的英文路径最后从解压目录双击 setup.exe。为什么要解压而不是直接挂载 ISO 运行因为安装程序在运行过程中会反复读取安装源文件如果直接从虚拟光驱读取某些虚拟化平台的驱动在长时间读取时会出现超时导致中途报错。解压到本地磁盘后这个问题基本不会出现。另外路径一定要用英文不要放在我的文档下载这类中文路径下也不要带空格和特殊符号我见过有人把安装包放在中文用户名下的桌面结果 SQL Server 的某些组件安装时路径解析异常。前置依赖的核对清单我在装之前一定会过一遍操作系统位数必须是 x64。SQL Server 2012 有 32 位版本但 32 位系统无法使用超过 4GB 内存数据库场景下没意义直接一律用 x64。.NET Framework 3.5 SP1这是 SQL Server 2012 安装程序的硬依赖Windows 8 及以上系统默认不启用需要提前在启用或关闭 Windows 功能里勾上。管理员权限安装程序必须以管理员身份运行否则在写入注册表和服务注册阶段会被拒绝。磁盘格式系统盘用 NTFS不要用 FAT32FAT32 单文件上限 4GB安装过程中生成的大文件会写不进去。杀毒软件安装期间建议临时关闭实时防护某些安全软件会把安装程序写入服务注册表的动作当成可疑行为拦截导致服务创建失败。Windows Installer 服务确认它在运行状态安装程序的 MSI 包依赖它。还有一个容易被忽略的点安装前把计算机名确定下来。SQL Server 的实例名和计算机名是绑定的如果你装完之后再改计算机名虽然数据库能启动但某些依赖名称解析的功能比如复制、链接服务器会出现问题处理起来很麻烦。所以虚拟机克隆出来的机器先改名重启再装数据库。2. 安装向导的第一阶段功能树、实例名、服务账户双击 setup.exe 之后安装中心会出现计划安装维护工具几个大项直接选左侧的安装然后点第一项全新 SQL Server 独立安装或向现有安装添加功能。接下来会依次经过产品密钥、许可条款、安装规则、功能选择、安装规则第二遍、实例配置、磁盘空间检查、服务器配置、数据库引擎配置、错误报告、安装规则第三遍这么一长串页面。很多人到这里就开始烦躁一路下一步点到底最后装出来一个自己都不知道装了什么的环境。这一段我想把三个真正需要动脑的页面拆开讲功能选择、实例配置、服务器配置。其余页面产品密钥、许可条款、错误报告按默认走就行产品密钥那里如果装的是 Developer 或 Express可能直接跳过或者填对应版本的密钥。2.1 功能选择页数据库引擎之外到底要不要勾功能选择页是整个安装过程中最考验判断力的一页因为它用一个树形列表把十几个组件摊在你面前每个都写着专业名词。我的原则很简单只勾你确定会用到的其余的装完随时可以补。SQL Server 支持后期通过安装中心向现有安装添加功能补充组件所以第一次安装没必要贪多。必须勾的是Database Engine Services数据库引擎服务这是核心不勾等于没装数据库。它下面还有两个子项SQL Server 复制和全文搜索。复制的用途是数据库之间的数据分发全文搜索用于对文本字段做分词检索。如果你要做的是课程设计里的数据同步类课题复制可以勾上如果只是普通增删改查这两个都可以先不勾需要时再补。客户端工具这一块管理工具-基本必须勾它包含 SQL Server Management Studio 的核心部分没有这个你连图形化界面都没有。管理工具-完整会多装一些性能和诊断工具我一般也勾上占用不大。SQL Server Data Tools是给做 ETL 和报表开发的人用的纯数据库运维不勾也没关系。客户端工具 SDK提供编程接口做应用开发的可以勾但通常开发机器上装个驱动就够。至于 Analysis Services、Reporting Services、Integration Services、Data Quality Services、Master Data Services 这五个属于商业智能和服务集成方向除非你的项目明确要求做多维分析、报表服务或者 ETL 流程否则不要勾。我见过有学员把这些全勾上装了两个多小时最后配置 Reporting Services 的时候又卡住折腾半天发现根本用不到。组件是否必勾典型用途数据库引擎服务必勾核心数据库功能管理工具-基本必勾图形化管理界面管理工具-完整建议勾性能与诊断工具SQL Server 复制按需数据分发与同步全文搜索按需文本分词检索Analysis/Reporting/Integration Services按需商业智能与 ETL2.2 实例配置默认实例和命名实例的取舍逻辑实例配置页有两个选项默认实例和命名实例。默认实例的名字就是计算机名一台机器上只能有一个命名实例可以装多个名字自己起比如MSSQL2012、DEV01。很多人纠结这一页其实判断标准就一条这台机器上是不是只有一个 SQL Server 环境。如果是一台干净的学习机只装这一个版本那就选默认实例省事连接的时候直接写localhost或者.就行不用记实例名。如果这台机器上已经有别的版本比如公司机器上原本装了 SQL Server 2008 R2或者你打算同时留着多个版本做兼容测试那必须用命名实例否则会直接报已存在默认实例。命名实例的命名要注意不要用中文不要带空格不要以数字开头长度控制在 16 个字符以内比较稳妥。我一般用MSSQL2012这种格式一眼能看出版本。连接的时候写法是计算机名\实例名比如localhost\MSSQL2012SQL Server Browser 服务负责把实例名解析成端口所以这个服务必须保持运行否则命名实例可能连不上。还有一个细节实例 ID 和实例名会自动关联默认装到C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER这样的目录下其中MSSQL11是 SQL Server 2012 的内部版本标识11.0。你看到 MSSQL11 就说明是 2012MSSQL10_50 是 2008 R2MSSQL12 是 2014这个规律在排错时很有用。2.3 服务账户与排序规则这两个下拉框别随手点服务器配置页要你给每个服务指定一个账户还要给整个实例选一个排序规则。这页看起来全是下拉框实际影响面很大。服务账户这一块SQL Server 2012 支持几种类型内置账户Local System、Network Service、Local Service、虚拟账户NT Service\MSSQLSERVER 这种格式、域账户、本地账户。我的推荐是用虚拟账户或者按服务分别指定。原因在于如果你在安装向导里给所有服务统一选一个账户等于把这些服务的权限耦合在一起某个服务被提权其他服务也跟着受益这不符合最小权限原则。具体做法是在这一页点对所有 SQL Server 服务使用相同的账户旁边的下拉改成为每个 SQL Server 服务使用单独的账户然后只给数据库引擎和 SQL Server 代理指定账户。数据库引擎用虚拟账户NT Service\MSSQLSERVER命名实例则是NT Service\MSSQL$实例名代理服务单独指定。虚拟账户的好处是不需要密码由系统管理权限边界清晰。如果你在域环境里并且要用到远程备份、链接服务器这些功能那就需要域账户这时候要提前让管理员创建好并且授予作为服务登录的权限。排序规则Collation这一项中文环境下最常选的是Chinese_PRC_CI_AS。它的含义可以拆开看Chinese_PRC表示简体中文CI是 Case Insensitive不区分大小写AS是 Accent Sensitive区分重音。另一种常见的是SQL_Latin1_General_CP1_CI_AS这是 SQL Server 的传统默认值对英文排序更快但对中文排序可能不合习惯。我的建议是如果项目里已经有明确的排序规则要求按需求来如果没有中文项目选Chinese_PRC_CI_AS更符合直觉。因为排序规则在实例级别一旦确定后期想改就得重建整个实例非常麻烦。数据库级别虽然可以单独指定不同的排序规则但跨排序规则做连接查询时会报错所以前期选对很重要。我见过有人装完才发现中文姓名排序是乱的就是因为默认用了 Latin1最后只能重建实例。3. 数据库引擎配置页身份验证模式与管理员账户数据库引擎配置页是整条安装流程里唯一一个会直接影响你能不能登进去的页面它要你决定两件大事身份验证模式以及哪些账户是这个实例的管理员。这两件事选错装完之后可能连自己都登不上去只能靠单用户模式恢复非常狼狈。3.1 Windows 身份验证和混合模式的真实差别身份验证模式有两个选项Windows 身份验证模式以及混合模式SQL Server 和 Windows 身份验证模式。这一页看起来只是两个单选按钮但它决定了后续所有连接的认证路径。Windows 身份验证模式的逻辑是你的 Windows 账户通过了数据库就认你。连接的时候不需要输账号密码SQL Server 直接拿当前 Windows 登录令牌去校验。这种方式安全性高因为凭据由操作系统统一管理不需要在数据库里存密码也避免了密码在网络传输中的风险。它的局限在于如果你的应用跑在另一台机器上、或者是个 Linux/容器环境、或者是个需要固定账号连接的后台服务就没法用它。混合模式则同时接受 Windows 账户和数据库内部的 SQL 登录账户最典型的就是sa账户。开启混合模式之后应用可以用sa或者自定义的 SQL 登录连接部署灵活性高。代价是要管理sa密码而且sa是默认的最高权限账户很多自动化攻击就是拿常见密码去撞sa所以密码强度和后续的账户策略必须跟上。我的实际选择是学习环境和需要给应用配置连接串的场景直接选混合模式。因为课程设计里经常要在 Java、C# 或者 Python 代码里写连接字符串用 SQL 登录最省事不用去处理 Windows 身份验证在跨机器场景下的委托问题。如果是纯内网、只有一个团队用、并且完全不跑外部应用那 Windows 身份验证模式更省心。混合模式并没有不安全不安全的是弱密码。3.2 sa 密码和指定 SQL Server 管理员选了混合模式之后指定 SQL Server 管理员这一栏就必须填内容了。这里分两块一是为sa账户指定密码二是添加当前用户或其他账户作为数据库管理员。sa密码的设置有几个硬性要求必须符合 Windows 密码策略如果启用了长度至少 8 位并且包含大小写字母、数字、符号中的三类。安装程序会实时校验太简单的密码直接不让过。我一般会设一个 12 位以上的强密码记录在密码管理器里日常不用它登录只在需要做实例级操作或者其他管理员账户全部锁死时作为最后手段。关于是否要把sa启用有个常见误区很多人以为安装时设了密码sa就是启用的。其实安装向导里设的只是密码账户默认处于禁用状态需要装完之后在 SSMS 里手动启用。这个设计是合理的因为它降低了默认攻击面。我的做法是安装时设好密码装完之后先不启用等到确实有需要比如某个应用只能用它连再启用并且启用后立刻检查登录失败日志。指定 SQL Server 管理员这里一定要点添加当前用户把当前登录的 Windows 账户加进去。这是很多人漏掉的一步——如果只设了sa密码却没添加任何 Windows 管理员而你装完之后又想用 Windows 身份验证登录就会发现自己进不去因为 Windows 账户在数据库里根本没有登录名。提示安装向导里添加管理员这一步是唯一一次能在不进入数据库的情况下配置实例管理员的机会。错过了就得靠单用户模式启动实例来补步骤麻烦得多。3.3 数据目录与 tempdb 的规划思路数据库引擎配置页还有第二个标签页叫数据目录用来指定数据文件、日志文件、备份文件、临时数据库的存放位置。很多人的做法是全部保持默认一路下一步。在单机学习环境里这样没问题但只要你稍微认真一点对待这个环境就应该在这里规划一下。默认路径通常是C:\Program Files\Microsoft SQL Server\MSSQL11.实例名\MSSQL\Data。问题在于这个路径在系统盘而系统盘通常是容量最小、写入最频繁的那块盘。数据库文件尤其是日志文件和 tempdb写入量非常大放在系统盘会拖慢系统响应还容易把盘写满。我的习惯是数据和日志分开放且都不要放系统盘。如果机器只有一块盘那就退而求其次全部放到一个单独创建的目录下比如D:\SQLData至少路径清晰、便于备份和迁移。如果有两块以上物理盘理想方案是数据文件放一块、日志文件放另一块因为数据文件是随机读写、日志文件是顺序追加写分开能减少 IO 竞争。备份文件放到第三块盘或者网络位置避免备份写满业务盘。tempdb 的规划比较特殊。它在实例级别只有一个但内部可以有多个数据文件。SQL Server 2012 默认建一个tempdb.mdf加一个tempdb_log.ldf。在高并发场景下多个查询争抢同一个 tempdb 数据文件的分配页会产生争用典型的缓解手段是按 CPU 核数建立对应数量的 tempdb 数据文件一般不超过 8 个并且把每个文件的初始大小设为相同值、关闭自动增长或设为固定增量。这些设置在安装向导里改不了需要在装完之后用 T-SQL 调整USE master; GO ALTER DATABASE tempdb MODIFY FILE (NAME tempdev, SIZE 512MB, FILEGROWTH 256MB); ALTER DATABASE tempdb ADD FILE (NAME tempdev2, FILENAME D:\SQLData\tempdb2.ndf, SIZE 512MB, FILEGROWTH 256MB); GO这段代码我做课设环境时一般不动但在做性能测试或者模拟并发场景时会加上。要注意的是修改 tempdb 文件数量后必须重启 SQL Server 服务才生效。4. 卡在规则检查上的几次真实经历安装向导里一共会出现三轮安装规则检查第一次在功能选择之前检查全局规则第二次在功能选择之后检查功能相关规则第三次在安装开始之前做最终检查。这三轮检查是安装失败最集中的地方。下面这三条报错我在不同机器上都真实遇到过把排查链路完整写出来你可以照着复现思路。4.1 .NET Framework 3.5 SP1 未安装的处理这是我在 Windows 10 和 Windows 11 上装 SQL Server 2012 遇到最多的报错原文大意是未安装 Microsoft .NET Framework 3.5 SP1需要它才能安装 SQL Server。奇怪的地方在于Windows 10 自带的是 .NET Framework 4.x感觉应该向下兼容但 SQL Server 2012 的安装程序会明确检查 3.5 这个特定版本是否被启用。原因在于 .NET Framework 4.x 虽然装了但它是一个独立版本并不替代 3.5。3.5 在 Windows 8 以后变成了一个按需启用的可选功能默认关闭。所以需要在系统层面把它开启。排查和修复的完整链路是这样的先打开控制面板进入程序和功能点左侧的启用或关闭 Windows 功能在弹出的列表里找到.NET Framework 3.5包括 .NET 2.0 和 3.0勾选它然后确定。如果系统能联网它会自动下载所需文件并完成启用。如果处于离线环境或者下载失败那就需要挂载对应版本的 Windows 安装介质用命令行从安装源指定路径启用DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /Source:D:\sources\sxs /LimitAccess这条命令里的D:\sources\sxs要换成你挂载的 Windows ISO 里sources\sxs目录的实际盘符。执行完之后会显示进度百分比最后提示操作成功。重启之后回到 SQL Server 安装程序重新跑一遍规则检查这一项就会变成通过。注意启用 .NET Framework 3.5 之后建议重启一次再继续安装我当时没重启直接点安装结果在服务注册阶段报了一次权限错误重启后重试就正常了。4.2 挂起的重新启动到底该怎么处理挂起的重新启动这条规则报的是计算机需要重新启动然后才能继续安装。它的本质是系统里存在一个待处理的文件重命名或替换操作通常是之前某个安装程序比如 .NET 更新、VC 运行库安装写入了注册表里的PendingFileRenameOperations键等着下次重启时执行。SQL Server 安装程序检测到这个标记出于安全考虑拒绝继续。最正规的处理方式当然是重启计算机。但实际工作中经常遇到的情况是重启了三次这条规则依然报错。这时候就要去查根因了。我遇到过一次原因是某个安全软件的驱动在每次启动时都会重新写入这个键形成死循环重启永远解决不了。排查这个问题的思路是分两步。第一步确认重启是否真的没有效果——重启后不要打开任何其他程序直接跑安装程序看规则是否通过。第二步如果重启无效去注册表定位问题HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager看右侧的PendingFileRenameOperations值是否存在。如果存在它的内容会告诉你是哪个文件在等待替换。看清内容之后如果是已知的软件残留可以先退出对应软件、卸载它再重启。关于直接删掉这个注册表值来强行通过检查我的态度是谨慎使用。这是一个绕过机制的做法删掉之后那个待替换的文件就不会被替换了可能留下一个版本不一致的隐患。如果只是为了在测试机上快速把数据库装上删之前务必备份注册表分支删完立刻重启并且记录下你删了什么内容方便日后追溯。4.3 性能计数器一致性检查失败的修复过程这条报错的全称大概是性能计数器注册表配置单元一致性检查失败典型症状是安装到安装规则第三轮时一个叫性能计数器或者PerformanceCounter的检查项亮红叉。这一项卡住的人不少因为它看起来和数据库八竿子打不着。根本原因在于 Windows 的性能计数器注册表信息和实际 DLL 文件对不上。可能的情况包括系统从旧版本升级过、某个应用程序安装时改坏了计数器注册、或者注册表里计数器的索引值被写乱。SQL Server 安装程序需要读取这些计数器来注册自己的性能对象比如 SQLServer:Buffer Manager 这些读不到就报错。修复的核心思路是重建性能计数器。Windows 提供了lodctr命令来做这件事在管理员权限的命令提示符下执行lodctr /R/R表示从注册表重建计数器信息。如果这一步提示失败还有一个配套命令需要先执行cd C:\Windows\SysWOW64 lodctr /R cd C:\Windows\System32 lodctr /R这两条要在 64 位系统上分别执行因为 32 位和 64 位的计数器是分开维护的。执行成功会显示信息: 成功重建性能计数器设置。做完之后不要急着重跑安装先重启一次然后再执行安装程序让规则检查重跑。我自己遇到过两次这条报错一次用lodctr /R直接解决了另一次在重建后仍然失败最后发现是注册表里HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib下的LastCounter和LastHelp两个值异常一个是空值一个数值范围不对把它们修正成与009子键中最大值一致后重启才通过。这一步操作涉及注册表风险较高建议先导出整个Perflib分支做备份。提示性能计数器修复完成后验证方法是在命令行执行typeperf \Processor(_Total)\% Processor Time -sc 1能正常输出一行采样数据就说明计数器已经可用。5. 安装完成后的验证与远程连接打通安装向导跑到最后一页会列出一堆成功安装的功能这时候很多人直接点关闭然后打开 SSMS 一看连不上或者连上了却发现少点东西。安装完成之后的验证和配置是这条流程里最容易被跳过、又最容易出问题的一段。5.1 用三条命令确认实例真的能用安装成功后第一件事打开 SQL Server Management Studio服务器名称栏里填localhost默认实例或者localhost\实例名命名实例身份验证那里选 Windows 身份验证点连接。如果连不上先别急着怀疑数据库坏了按顺序排查打开服务services.msc看 SQL Server (MSSQLSERVER) 或 SQL Server (实例名) 这个服务是不是正在运行。安装完不自动启动的情况我遇到过手动启动一下就好了。连上之后新建一个查询窗口跑下面这一条把版本、版本号、实例名一次性看全SELECT VERSION AS 版本信息, SERVERPROPERTY(ProductVersion) AS 版本号, SERVERPROPERTY(Edition) AS 版本类型, SERVERPROPERTY(InstanceName) AS 实例名, SERVERPROPERTY(Collation) AS 排序规则;VERSION会输出一段长字符串里面包含操作系统版本、SQL Server 版本和补丁级别。看补丁级别的方法是找(SP4)这种标记如果没有 SP 标记说明是原始版本。ProductVersion会是11.x.xxxx.x这种格式前两位11代表主机版本是 2012后面几段对应具体补丁。第二条要验证的是能不能建库建表跑一遍最小闭环CREATE DATABASE demo_check; GO USE demo_check; GO CREATE TABLE t1 (id INT IDENTITY PRIMARY KEY, name NVARCHAR(50)); INSERT INTO t1 (name) VALUES (N测试), (N验证); SELECT * FROM t1; GO USE master; DROP DATABASE demo_check;这段跑通说明数据库引擎的读写、事务日志、系统库都正常。跑不通的话错误信息通常会指向权限或者磁盘路径问题比连接失败好定位得多。第三条是验证服务依赖是否齐全。在 SSMS 里展开管理→SQL Server 日志看有没有启动失败或者警告级别的条目。另外打开 SQL Server 配置管理器看SQL Server 服务下面哪些是运行状态SQL Server 网络配置下面哪些协议已启用。这一屏信息量很大值得花一分钟看一遍。5.2 补丁级别、兼容性级别和版本号怎么对这一节讲三个经常被混为一谈的概念。很多人说我的数据库版本是 2012其实指的是主机版本但同一个主机版本下补丁级别可以差很多兼容性级别又是另一回事。主机版本就是 11.x对应 SQL Server 2012。它决定了安装介质是哪一代。补丁级别指的是有没有打服务包和累积更新。SQL Server 2012 的最终服务包是 SP4SP4 之后还有若干个累积更新。查看补丁级别用SELECT VERSION或者SERVERPROPERTY(ProductLevel)后者会直接返回SP4或者RTM这种简明值。补丁级别影响的是已修复的缺陷和潜在的安全问题所以装完老版本之后打补丁是常规操作。兼容性级别是数据库层面的设置用ALTER DATABASE ... SET COMPATIBILITY_LEVEL调整SQL Server 2012 对应的是 110。它决定的是 T-SQL 语法和行为按哪一代的规则执行比如某些日期函数在新一代里行为变了兼容性级别会影响参数嗅探和基数估算的行为。查看方法SELECT name, compatibility_level FROM sys.databases;很多人升级了数据库版本但兼容性级别还停留在老版本导致优化器不能使用新的估算模型。一般情况下如果你确认应用在新行为下没问题可以把兼容性级别提到 110如果是从更老的版本迁移过来的老应用保守起见先保持原级别等测试充分再调整。概念查看方式典型值影响范围主机版本VERSION 前段11.x安装介质所属代次补丁级别SERVERPROPERTY(ProductLevel)RTM / SP4缺陷修复与安全兼容性级别sys.databases 查询110T-SQL 行为与优化器5.3 开启 TCP/IP、固定端口与放行入站默认安装出来的实例只在本机通过共享内存或者命名管道提供访问外部应用想通过网络连是连不上的。打通远程连接需要动三个地方缺一不可。第一步是启用 TCP/IP 协议。打开 SQL Server 配置管理器展开SQL Server 网络配置→实例名 的协议右键 TCP/IP选启用然后重启 SQL Server 服务。重启之后协议才真正生效这一步经常被忘记很多人点完启用就以为好了结果还是连不上。第二步是确认端口。还是在 TCP/IP 属性里切到IP 地址标签页拉到底部的IPAll区域。默认情况下 TCP 动态端口是 0意思是 SQL Server 每次启动随机挑一个端口这对防火墙策略非常不友好。我的做法是把TCP 动态端口清空TCP 端口填 1433这样端口固定防火墙规则才能写死。命名实例共用 1433 会冲突所以命名实例要么用别的端口比如 1434 保留给浏览器服务那就用 14330 这类高位端口要么靠 SQL Server Browser 服务动态解析。第三步是防火墙放行。在高级安全 Windows 防火墙里新建一条入站规则类型选端口协议 TCP特定本地端口填你上面设的端口号操作选允许连接配置文件勾上域、专用、公用按你的网络环境来起个名字比如SQL Server 2012 1433。三步做完在另一台机器上用 SSMS 连接服务器IP,端口号试试。如果连不上按这个顺序查先在本机telnet 127.0.0.1 1433确认端口在监听再从外部telnet 服务器IP 1433确认防火墙放行最后检查 SQL Server 自身的登录名和权限。这个分层的排查顺序很关键能帮你快速锁定是网络层、防火墙层还是数据库层的问题而不是瞎试。telnet 127.0.0.1 1433 telnet 192.168.1.100 1433注意开放 1433 到公网是非常危险的做法自动化扫描会持续尝试爆破 sa 账户。远程连接只在内网或者安全组白名单范围内开放公网暴露的场景请通过其他安全机制做访问控制。6. 长期使用中我坚持的几个小习惯装完一个 SQL Server 2012 实例只是开始真正决定这个环境好不好用的是后续的维护习惯。分享几个我自己一直在做的动作。第一件事是装完立刻做一次基线备份。把 master、model、msdb 三个系统库各备份一份连同当前的补丁级别、排序规则、实例配置一起记在一个文本文件里。原因很简单一旦后续因为某个操作把实例搞坏有基线就能对照知道哪些东西变了。我遇到过一次实例无法启动的情况就是靠对比基线发现是某个服务账户被人改了密码。第二件事是把常用的连接方式记下来包括本机连接、IP 连接、命名实例连接三种写法的实际值。很多时候环境是自己装的但过两个月再回来用就忘了实例名和端口。我一般会直接在项目根目录放一个env-note.md记录实例名、端口、sa密码存放位置不存密码本身只存提示、数据目录路径团队协作的时候这份记录能省掉大量沟通成本。第三件事是控制sa的使用范围。我的习惯是给每个应用单独建一个登录名只授予它需要的那几个数据库的权限应用连接串里绝不出现sa。这样即使某个应用的连接串泄露影响面也被限制在它自己的库上。sa只在做实例级维护时临时启用用完就禁用。第四件事是关于老环境的心态。SQL Server 2012 是个成熟的、稳定的老版本把它当学习工具、当兼容测试的靶机非常合适但如果是要长期承载业务就需要正视它已经过了支持周期这个事实。我自己的处理方式是实验环境随便装、随便折腾生产相关的迁移评估尽早启动。最后再补一个小技巧。如果你在虚拟机里装装之前给虚拟机打一个干净的快照装完之后再打一个装好数据库的快照。后续无论装什么新东西导致环境乱掉回滚到装好数据库那个快照只要几十秒比重装一遍快得多。这个习惯帮我在做数据库课程设计辅导的时候节省了大量时间——学生把实例玩坏了回滚一下就好不用等一个小时重装。 SQL Server 2012安装步骤详解：版本、实例配置与报错修复
1. 装之前先把版本和硬件底线捋清楚装 SQL Server 2012 这件事说难不难说简单也容易翻车。我在物理机、VMware 虚拟机、云主机上前后装过二十来遍最顺的一次从双击 setup.exe 到能跑通查询只花了十几分钟最折腾的一次卡在性能计数器一致性那条规则上耗掉整整一个下午。这篇安装步骤详解就是把这二十来遍的经验压成一条尽量不绕弯的路把每一步为什么这么选讲透。先说清楚这篇内容适合谁一是做课程设计、毕业设计需要在本地起一个能连能用的实例二是接手老系统要复现一个 SQL Server 2012 环境做兼容性验证三是第一次面对 SQL Server 安装向导被一堆规则检查和功能树弄得不知道该勾哪个的新手。核心就三件事——数据库、SQL Server 2012、安装步骤后面所有内容都围绕这三件事展开不讲虚的。1.1 课程设计、测试、生产三种场景对应三种版本SQL Server 2012 的版本谱系比很多人想象的复杂Enterprise企业版、Business Intelligence商业智能版、Standard标准版、Web 版、Developer开发版、Express简易版。很多人第一反应是装企业版最保险这个思路在课程设计阶段其实是个坑因为企业版的功能树会多出大量平时根本用不到的服务安装时间和后续维护成本都上去了。选版本的正确姿势是从用途反推。做数据库课程设计、毕业设计、个人练手Developer 版是最优解——它的功能集和企业版完全一致包括分区表、AlwaysOn、数据压缩这些高级特性唯一限制是授权只允许用于开发和测试不允许上生产。你拿它跑课设、跑实验、跑性能测试一点问题都没有。如果是给一个小团队内部用的实际业务系统Standard 版足够覆盖绝大多数场景它对 CPU 插槽数和内存有上限但对中小型业务完全够用。Express 版适合做嵌入式或者学习入门数据库单库上限 10GB内存最大用 1GB连个稍大点的数据集就开始吃力我一般只在需要快速给学员发一个免安装式练习环境时才用它。还有一点常被忽略SQL Server 2012 是 2012 年发布的它的官方生命周期早已结束最后一个服务包是 SP4。这意味着如果你打算把它用在实际业务上安全补丁的获取需要谨慎评估但在离线实验环境、内网培训环境、老系统兼容验证环境里它依然是个稳定的选择。我的建议是学习和测试随便装生产环境请评估替代方案。版本适用场景主要限制我的推荐度Developer课程设计、开发测试不可用于生产强烈推荐Standard中小型业务系统CPU/内存有上限推荐Enterprise大型业务、高可用成本高、安装重视需求Express入门学习、嵌入式单库 10GB、内存 1GB入门可用1.2 硬件与操作系统的实际底线含参数表官方文档给的最低配置看起来非常宽松x64 处理器 1.0 GHz 以上1GB 内存6GB 磁盘空间。但按这个底线装出来的实例你打开 Management Studio 连上去点两下就会开始怀疑人生。这是我踩过的第一个坑——当年在 2GB 内存的虚拟机上装完恢复一个几百兆的备份文件花了快四十分钟。我的实际经验值是这样的处理器双核 2.0 GHz 起步内存 4GB 是舒适线8GB 以上才能同时跑数据库和开发工具不卡顿。磁盘方面程序文件加系统数据库master、model、msdb、tempdb装完大概占 4 到 8GB但你至少要留出 20GB 以上的空闲空间因为 tempdb 会随查询规模膨胀日志文件也会长。磁盘类型这一项很多人不在意但差距巨大。机械硬盘上装 SQL Server光是启动服务就要几十秒换成 SSD 之后同样的实例启动通常在三秒内完成恢复备份的速度能差好几倍。如果你在用虚拟机务必把虚拟磁盘放在 SSD 上并且优先选固定大小而不是动态扩展动态扩展盘在数据库写入场景下会频繁触发扩容性能抖动非常明显。操作系统这一项需要单独提醒。SQL Server 2012 原生支持的是 Windows 7 SP1、Windows Server 2008 R2 SP1、Windows 8 / 8.1、Windows Server 2012 / 2012 R2 这一代系统。如果你在 Windows 10 或 Windows 11 上安装会遇到两个典型问题一是 .NET Framework 3.5 默认没启用安装程序会直接报依赖缺失二是部分规则检查项会因为系统版本超出预期范围而失败。这不是不能装而是需要额外处理后面第 4 章我会专门讲怎么过这两关。项目官方最低我的建议值说明CPU1.0 GHz x64双核 2.0 GHz影响查询并发能力内存1GB4GB 起8GB 舒适低于 4GB 恢复备份很慢磁盘空间6GB预留 20GBtempdb 和日志会增长磁盘类型无要求SSD启动和恢复速度差距巨大操作系统Win7 SP1 / Server 2008 R2 SP1同代系统最稳新版系统需额外处理1.3 安装介质与前置依赖的核对清单安装介质这块最常见的翻车方式是拿着一个来路不明的 ISO 直接挂载运行结果卡在提取文件失败或者安装到一半报安装程序文件损坏。我的做法固定是三步先校验文件哈希再解压到本地硬盘的英文路径最后从解压目录双击 setup.exe。为什么要解压而不是直接挂载 ISO 运行因为安装程序在运行过程中会反复读取安装源文件如果直接从虚拟光驱读取某些虚拟化平台的驱动在长时间读取时会出现超时导致中途报错。解压到本地磁盘后这个问题基本不会出现。另外路径一定要用英文不要放在我的文档下载这类中文路径下也不要带空格和特殊符号我见过有人把安装包放在中文用户名下的桌面结果 SQL Server 的某些组件安装时路径解析异常。前置依赖的核对清单我在装之前一定会过一遍操作系统位数必须是 x64。SQL Server 2012 有 32 位版本但 32 位系统无法使用超过 4GB 内存数据库场景下没意义直接一律用 x64。.NET Framework 3.5 SP1这是 SQL Server 2012 安装程序的硬依赖Windows 8 及以上系统默认不启用需要提前在启用或关闭 Windows 功能里勾上。管理员权限安装程序必须以管理员身份运行否则在写入注册表和服务注册阶段会被拒绝。磁盘格式系统盘用 NTFS不要用 FAT32FAT32 单文件上限 4GB安装过程中生成的大文件会写不进去。杀毒软件安装期间建议临时关闭实时防护某些安全软件会把安装程序写入服务注册表的动作当成可疑行为拦截导致服务创建失败。Windows Installer 服务确认它在运行状态安装程序的 MSI 包依赖它。还有一个容易被忽略的点安装前把计算机名确定下来。SQL Server 的实例名和计算机名是绑定的如果你装完之后再改计算机名虽然数据库能启动但某些依赖名称解析的功能比如复制、链接服务器会出现问题处理起来很麻烦。所以虚拟机克隆出来的机器先改名重启再装数据库。2. 安装向导的第一阶段功能树、实例名、服务账户双击 setup.exe 之后安装中心会出现计划安装维护工具几个大项直接选左侧的安装然后点第一项全新 SQL Server 独立安装或向现有安装添加功能。接下来会依次经过产品密钥、许可条款、安装规则、功能选择、安装规则第二遍、实例配置、磁盘空间检查、服务器配置、数据库引擎配置、错误报告、安装规则第三遍这么一长串页面。很多人到这里就开始烦躁一路下一步点到底最后装出来一个自己都不知道装了什么的环境。这一段我想把三个真正需要动脑的页面拆开讲功能选择、实例配置、服务器配置。其余页面产品密钥、许可条款、错误报告按默认走就行产品密钥那里如果装的是 Developer 或 Express可能直接跳过或者填对应版本的密钥。2.1 功能选择页数据库引擎之外到底要不要勾功能选择页是整个安装过程中最考验判断力的一页因为它用一个树形列表把十几个组件摊在你面前每个都写着专业名词。我的原则很简单只勾你确定会用到的其余的装完随时可以补。SQL Server 支持后期通过安装中心向现有安装添加功能补充组件所以第一次安装没必要贪多。必须勾的是Database Engine Services数据库引擎服务这是核心不勾等于没装数据库。它下面还有两个子项SQL Server 复制和全文搜索。复制的用途是数据库之间的数据分发全文搜索用于对文本字段做分词检索。如果你要做的是课程设计里的数据同步类课题复制可以勾上如果只是普通增删改查这两个都可以先不勾需要时再补。客户端工具这一块管理工具-基本必须勾它包含 SQL Server Management Studio 的核心部分没有这个你连图形化界面都没有。管理工具-完整会多装一些性能和诊断工具我一般也勾上占用不大。SQL Server Data Tools是给做 ETL 和报表开发的人用的纯数据库运维不勾也没关系。客户端工具 SDK提供编程接口做应用开发的可以勾但通常开发机器上装个驱动就够。至于 Analysis Services、Reporting Services、Integration Services、Data Quality Services、Master Data Services 这五个属于商业智能和服务集成方向除非你的项目明确要求做多维分析、报表服务或者 ETL 流程否则不要勾。我见过有学员把这些全勾上装了两个多小时最后配置 Reporting Services 的时候又卡住折腾半天发现根本用不到。组件是否必勾典型用途数据库引擎服务必勾核心数据库功能管理工具-基本必勾图形化管理界面管理工具-完整建议勾性能与诊断工具SQL Server 复制按需数据分发与同步全文搜索按需文本分词检索Analysis/Reporting/Integration Services按需商业智能与 ETL2.2 实例配置默认实例和命名实例的取舍逻辑实例配置页有两个选项默认实例和命名实例。默认实例的名字就是计算机名一台机器上只能有一个命名实例可以装多个名字自己起比如MSSQL2012、DEV01。很多人纠结这一页其实判断标准就一条这台机器上是不是只有一个 SQL Server 环境。如果是一台干净的学习机只装这一个版本那就选默认实例省事连接的时候直接写localhost或者.就行不用记实例名。如果这台机器上已经有别的版本比如公司机器上原本装了 SQL Server 2008 R2或者你打算同时留着多个版本做兼容测试那必须用命名实例否则会直接报已存在默认实例。命名实例的命名要注意不要用中文不要带空格不要以数字开头长度控制在 16 个字符以内比较稳妥。我一般用MSSQL2012这种格式一眼能看出版本。连接的时候写法是计算机名\实例名比如localhost\MSSQL2012SQL Server Browser 服务负责把实例名解析成端口所以这个服务必须保持运行否则命名实例可能连不上。还有一个细节实例 ID 和实例名会自动关联默认装到C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER这样的目录下其中MSSQL11是 SQL Server 2012 的内部版本标识11.0。你看到 MSSQL11 就说明是 2012MSSQL10_50 是 2008 R2MSSQL12 是 2014这个规律在排错时很有用。2.3 服务账户与排序规则这两个下拉框别随手点服务器配置页要你给每个服务指定一个账户还要给整个实例选一个排序规则。这页看起来全是下拉框实际影响面很大。服务账户这一块SQL Server 2012 支持几种类型内置账户Local System、Network Service、Local Service、虚拟账户NT Service\MSSQLSERVER 这种格式、域账户、本地账户。我的推荐是用虚拟账户或者按服务分别指定。原因在于如果你在安装向导里给所有服务统一选一个账户等于把这些服务的权限耦合在一起某个服务被提权其他服务也跟着受益这不符合最小权限原则。具体做法是在这一页点对所有 SQL Server 服务使用相同的账户旁边的下拉改成为每个 SQL Server 服务使用单独的账户然后只给数据库引擎和 SQL Server 代理指定账户。数据库引擎用虚拟账户NT Service\MSSQLSERVER命名实例则是NT Service\MSSQL$实例名代理服务单独指定。虚拟账户的好处是不需要密码由系统管理权限边界清晰。如果你在域环境里并且要用到远程备份、链接服务器这些功能那就需要域账户这时候要提前让管理员创建好并且授予作为服务登录的权限。排序规则Collation这一项中文环境下最常选的是Chinese_PRC_CI_AS。它的含义可以拆开看Chinese_PRC表示简体中文CI是 Case Insensitive不区分大小写AS是 Accent Sensitive区分重音。另一种常见的是SQL_Latin1_General_CP1_CI_AS这是 SQL Server 的传统默认值对英文排序更快但对中文排序可能不合习惯。我的建议是如果项目里已经有明确的排序规则要求按需求来如果没有中文项目选Chinese_PRC_CI_AS更符合直觉。因为排序规则在实例级别一旦确定后期想改就得重建整个实例非常麻烦。数据库级别虽然可以单独指定不同的排序规则但跨排序规则做连接查询时会报错所以前期选对很重要。我见过有人装完才发现中文姓名排序是乱的就是因为默认用了 Latin1最后只能重建实例。3. 数据库引擎配置页身份验证模式与管理员账户数据库引擎配置页是整条安装流程里唯一一个会直接影响你能不能登进去的页面它要你决定两件大事身份验证模式以及哪些账户是这个实例的管理员。这两件事选错装完之后可能连自己都登不上去只能靠单用户模式恢复非常狼狈。3.1 Windows 身份验证和混合模式的真实差别身份验证模式有两个选项Windows 身份验证模式以及混合模式SQL Server 和 Windows 身份验证模式。这一页看起来只是两个单选按钮但它决定了后续所有连接的认证路径。Windows 身份验证模式的逻辑是你的 Windows 账户通过了数据库就认你。连接的时候不需要输账号密码SQL Server 直接拿当前 Windows 登录令牌去校验。这种方式安全性高因为凭据由操作系统统一管理不需要在数据库里存密码也避免了密码在网络传输中的风险。它的局限在于如果你的应用跑在另一台机器上、或者是个 Linux/容器环境、或者是个需要固定账号连接的后台服务就没法用它。混合模式则同时接受 Windows 账户和数据库内部的 SQL 登录账户最典型的就是sa账户。开启混合模式之后应用可以用sa或者自定义的 SQL 登录连接部署灵活性高。代价是要管理sa密码而且sa是默认的最高权限账户很多自动化攻击就是拿常见密码去撞sa所以密码强度和后续的账户策略必须跟上。我的实际选择是学习环境和需要给应用配置连接串的场景直接选混合模式。因为课程设计里经常要在 Java、C# 或者 Python 代码里写连接字符串用 SQL 登录最省事不用去处理 Windows 身份验证在跨机器场景下的委托问题。如果是纯内网、只有一个团队用、并且完全不跑外部应用那 Windows 身份验证模式更省心。混合模式并没有不安全不安全的是弱密码。3.2 sa 密码和指定 SQL Server 管理员选了混合模式之后指定 SQL Server 管理员这一栏就必须填内容了。这里分两块一是为sa账户指定密码二是添加当前用户或其他账户作为数据库管理员。sa密码的设置有几个硬性要求必须符合 Windows 密码策略如果启用了长度至少 8 位并且包含大小写字母、数字、符号中的三类。安装程序会实时校验太简单的密码直接不让过。我一般会设一个 12 位以上的强密码记录在密码管理器里日常不用它登录只在需要做实例级操作或者其他管理员账户全部锁死时作为最后手段。关于是否要把sa启用有个常见误区很多人以为安装时设了密码sa就是启用的。其实安装向导里设的只是密码账户默认处于禁用状态需要装完之后在 SSMS 里手动启用。这个设计是合理的因为它降低了默认攻击面。我的做法是安装时设好密码装完之后先不启用等到确实有需要比如某个应用只能用它连再启用并且启用后立刻检查登录失败日志。指定 SQL Server 管理员这里一定要点添加当前用户把当前登录的 Windows 账户加进去。这是很多人漏掉的一步——如果只设了sa密码却没添加任何 Windows 管理员而你装完之后又想用 Windows 身份验证登录就会发现自己进不去因为 Windows 账户在数据库里根本没有登录名。提示安装向导里添加管理员这一步是唯一一次能在不进入数据库的情况下配置实例管理员的机会。错过了就得靠单用户模式启动实例来补步骤麻烦得多。3.3 数据目录与 tempdb 的规划思路数据库引擎配置页还有第二个标签页叫数据目录用来指定数据文件、日志文件、备份文件、临时数据库的存放位置。很多人的做法是全部保持默认一路下一步。在单机学习环境里这样没问题但只要你稍微认真一点对待这个环境就应该在这里规划一下。默认路径通常是C:\Program Files\Microsoft SQL Server\MSSQL11.实例名\MSSQL\Data。问题在于这个路径在系统盘而系统盘通常是容量最小、写入最频繁的那块盘。数据库文件尤其是日志文件和 tempdb写入量非常大放在系统盘会拖慢系统响应还容易把盘写满。我的习惯是数据和日志分开放且都不要放系统盘。如果机器只有一块盘那就退而求其次全部放到一个单独创建的目录下比如D:\SQLData至少路径清晰、便于备份和迁移。如果有两块以上物理盘理想方案是数据文件放一块、日志文件放另一块因为数据文件是随机读写、日志文件是顺序追加写分开能减少 IO 竞争。备份文件放到第三块盘或者网络位置避免备份写满业务盘。tempdb 的规划比较特殊。它在实例级别只有一个但内部可以有多个数据文件。SQL Server 2012 默认建一个tempdb.mdf加一个tempdb_log.ldf。在高并发场景下多个查询争抢同一个 tempdb 数据文件的分配页会产生争用典型的缓解手段是按 CPU 核数建立对应数量的 tempdb 数据文件一般不超过 8 个并且把每个文件的初始大小设为相同值、关闭自动增长或设为固定增量。这些设置在安装向导里改不了需要在装完之后用 T-SQL 调整USE master; GO ALTER DATABASE tempdb MODIFY FILE (NAME tempdev, SIZE 512MB, FILEGROWTH 256MB); ALTER DATABASE tempdb ADD FILE (NAME tempdev2, FILENAME D:\SQLData\tempdb2.ndf, SIZE 512MB, FILEGROWTH 256MB); GO这段代码我做课设环境时一般不动但在做性能测试或者模拟并发场景时会加上。要注意的是修改 tempdb 文件数量后必须重启 SQL Server 服务才生效。4. 卡在规则检查上的几次真实经历安装向导里一共会出现三轮安装规则检查第一次在功能选择之前检查全局规则第二次在功能选择之后检查功能相关规则第三次在安装开始之前做最终检查。这三轮检查是安装失败最集中的地方。下面这三条报错我在不同机器上都真实遇到过把排查链路完整写出来你可以照着复现思路。4.1 .NET Framework 3.5 SP1 未安装的处理这是我在 Windows 10 和 Windows 11 上装 SQL Server 2012 遇到最多的报错原文大意是未安装 Microsoft .NET Framework 3.5 SP1需要它才能安装 SQL Server。奇怪的地方在于Windows 10 自带的是 .NET Framework 4.x感觉应该向下兼容但 SQL Server 2012 的安装程序会明确检查 3.5 这个特定版本是否被启用。原因在于 .NET Framework 4.x 虽然装了但它是一个独立版本并不替代 3.5。3.5 在 Windows 8 以后变成了一个按需启用的可选功能默认关闭。所以需要在系统层面把它开启。排查和修复的完整链路是这样的先打开控制面板进入程序和功能点左侧的启用或关闭 Windows 功能在弹出的列表里找到.NET Framework 3.5包括 .NET 2.0 和 3.0勾选它然后确定。如果系统能联网它会自动下载所需文件并完成启用。如果处于离线环境或者下载失败那就需要挂载对应版本的 Windows 安装介质用命令行从安装源指定路径启用DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /Source:D:\sources\sxs /LimitAccess这条命令里的D:\sources\sxs要换成你挂载的 Windows ISO 里sources\sxs目录的实际盘符。执行完之后会显示进度百分比最后提示操作成功。重启之后回到 SQL Server 安装程序重新跑一遍规则检查这一项就会变成通过。注意启用 .NET Framework 3.5 之后建议重启一次再继续安装我当时没重启直接点安装结果在服务注册阶段报了一次权限错误重启后重试就正常了。4.2 挂起的重新启动到底该怎么处理挂起的重新启动这条规则报的是计算机需要重新启动然后才能继续安装。它的本质是系统里存在一个待处理的文件重命名或替换操作通常是之前某个安装程序比如 .NET 更新、VC 运行库安装写入了注册表里的PendingFileRenameOperations键等着下次重启时执行。SQL Server 安装程序检测到这个标记出于安全考虑拒绝继续。最正规的处理方式当然是重启计算机。但实际工作中经常遇到的情况是重启了三次这条规则依然报错。这时候就要去查根因了。我遇到过一次原因是某个安全软件的驱动在每次启动时都会重新写入这个键形成死循环重启永远解决不了。排查这个问题的思路是分两步。第一步确认重启是否真的没有效果——重启后不要打开任何其他程序直接跑安装程序看规则是否通过。第二步如果重启无效去注册表定位问题HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager看右侧的PendingFileRenameOperations值是否存在。如果存在它的内容会告诉你是哪个文件在等待替换。看清内容之后如果是已知的软件残留可以先退出对应软件、卸载它再重启。关于直接删掉这个注册表值来强行通过检查我的态度是谨慎使用。这是一个绕过机制的做法删掉之后那个待替换的文件就不会被替换了可能留下一个版本不一致的隐患。如果只是为了在测试机上快速把数据库装上删之前务必备份注册表分支删完立刻重启并且记录下你删了什么内容方便日后追溯。4.3 性能计数器一致性检查失败的修复过程这条报错的全称大概是性能计数器注册表配置单元一致性检查失败典型症状是安装到安装规则第三轮时一个叫性能计数器或者PerformanceCounter的检查项亮红叉。这一项卡住的人不少因为它看起来和数据库八竿子打不着。根本原因在于 Windows 的性能计数器注册表信息和实际 DLL 文件对不上。可能的情况包括系统从旧版本升级过、某个应用程序安装时改坏了计数器注册、或者注册表里计数器的索引值被写乱。SQL Server 安装程序需要读取这些计数器来注册自己的性能对象比如 SQLServer:Buffer Manager 这些读不到就报错。修复的核心思路是重建性能计数器。Windows 提供了lodctr命令来做这件事在管理员权限的命令提示符下执行lodctr /R/R表示从注册表重建计数器信息。如果这一步提示失败还有一个配套命令需要先执行cd C:\Windows\SysWOW64 lodctr /R cd C:\Windows\System32 lodctr /R这两条要在 64 位系统上分别执行因为 32 位和 64 位的计数器是分开维护的。执行成功会显示信息: 成功重建性能计数器设置。做完之后不要急着重跑安装先重启一次然后再执行安装程序让规则检查重跑。我自己遇到过两次这条报错一次用lodctr /R直接解决了另一次在重建后仍然失败最后发现是注册表里HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib下的LastCounter和LastHelp两个值异常一个是空值一个数值范围不对把它们修正成与009子键中最大值一致后重启才通过。这一步操作涉及注册表风险较高建议先导出整个Perflib分支做备份。提示性能计数器修复完成后验证方法是在命令行执行typeperf \Processor(_Total)\% Processor Time -sc 1能正常输出一行采样数据就说明计数器已经可用。5. 安装完成后的验证与远程连接打通安装向导跑到最后一页会列出一堆成功安装的功能这时候很多人直接点关闭然后打开 SSMS 一看连不上或者连上了却发现少点东西。安装完成之后的验证和配置是这条流程里最容易被跳过、又最容易出问题的一段。5.1 用三条命令确认实例真的能用安装成功后第一件事打开 SQL Server Management Studio服务器名称栏里填localhost默认实例或者localhost\实例名命名实例身份验证那里选 Windows 身份验证点连接。如果连不上先别急着怀疑数据库坏了按顺序排查打开服务services.msc看 SQL Server (MSSQLSERVER) 或 SQL Server (实例名) 这个服务是不是正在运行。安装完不自动启动的情况我遇到过手动启动一下就好了。连上之后新建一个查询窗口跑下面这一条把版本、版本号、实例名一次性看全SELECT VERSION AS 版本信息, SERVERPROPERTY(ProductVersion) AS 版本号, SERVERPROPERTY(Edition) AS 版本类型, SERVERPROPERTY(InstanceName) AS 实例名, SERVERPROPERTY(Collation) AS 排序规则;VERSION会输出一段长字符串里面包含操作系统版本、SQL Server 版本和补丁级别。看补丁级别的方法是找(SP4)这种标记如果没有 SP 标记说明是原始版本。ProductVersion会是11.x.xxxx.x这种格式前两位11代表主机版本是 2012后面几段对应具体补丁。第二条要验证的是能不能建库建表跑一遍最小闭环CREATE DATABASE demo_check; GO USE demo_check; GO CREATE TABLE t1 (id INT IDENTITY PRIMARY KEY, name NVARCHAR(50)); INSERT INTO t1 (name) VALUES (N测试), (N验证); SELECT * FROM t1; GO USE master; DROP DATABASE demo_check;这段跑通说明数据库引擎的读写、事务日志、系统库都正常。跑不通的话错误信息通常会指向权限或者磁盘路径问题比连接失败好定位得多。第三条是验证服务依赖是否齐全。在 SSMS 里展开管理→SQL Server 日志看有没有启动失败或者警告级别的条目。另外打开 SQL Server 配置管理器看SQL Server 服务下面哪些是运行状态SQL Server 网络配置下面哪些协议已启用。这一屏信息量很大值得花一分钟看一遍。5.2 补丁级别、兼容性级别和版本号怎么对这一节讲三个经常被混为一谈的概念。很多人说我的数据库版本是 2012其实指的是主机版本但同一个主机版本下补丁级别可以差很多兼容性级别又是另一回事。主机版本就是 11.x对应 SQL Server 2012。它决定了安装介质是哪一代。补丁级别指的是有没有打服务包和累积更新。SQL Server 2012 的最终服务包是 SP4SP4 之后还有若干个累积更新。查看补丁级别用SELECT VERSION或者SERVERPROPERTY(ProductLevel)后者会直接返回SP4或者RTM这种简明值。补丁级别影响的是已修复的缺陷和潜在的安全问题所以装完老版本之后打补丁是常规操作。兼容性级别是数据库层面的设置用ALTER DATABASE ... SET COMPATIBILITY_LEVEL调整SQL Server 2012 对应的是 110。它决定的是 T-SQL 语法和行为按哪一代的规则执行比如某些日期函数在新一代里行为变了兼容性级别会影响参数嗅探和基数估算的行为。查看方法SELECT name, compatibility_level FROM sys.databases;很多人升级了数据库版本但兼容性级别还停留在老版本导致优化器不能使用新的估算模型。一般情况下如果你确认应用在新行为下没问题可以把兼容性级别提到 110如果是从更老的版本迁移过来的老应用保守起见先保持原级别等测试充分再调整。概念查看方式典型值影响范围主机版本VERSION 前段11.x安装介质所属代次补丁级别SERVERPROPERTY(ProductLevel)RTM / SP4缺陷修复与安全兼容性级别sys.databases 查询110T-SQL 行为与优化器5.3 开启 TCP/IP、固定端口与放行入站默认安装出来的实例只在本机通过共享内存或者命名管道提供访问外部应用想通过网络连是连不上的。打通远程连接需要动三个地方缺一不可。第一步是启用 TCP/IP 协议。打开 SQL Server 配置管理器展开SQL Server 网络配置→实例名 的协议右键 TCP/IP选启用然后重启 SQL Server 服务。重启之后协议才真正生效这一步经常被忘记很多人点完启用就以为好了结果还是连不上。第二步是确认端口。还是在 TCP/IP 属性里切到IP 地址标签页拉到底部的IPAll区域。默认情况下 TCP 动态端口是 0意思是 SQL Server 每次启动随机挑一个端口这对防火墙策略非常不友好。我的做法是把TCP 动态端口清空TCP 端口填 1433这样端口固定防火墙规则才能写死。命名实例共用 1433 会冲突所以命名实例要么用别的端口比如 1434 保留给浏览器服务那就用 14330 这类高位端口要么靠 SQL Server Browser 服务动态解析。第三步是防火墙放行。在高级安全 Windows 防火墙里新建一条入站规则类型选端口协议 TCP特定本地端口填你上面设的端口号操作选允许连接配置文件勾上域、专用、公用按你的网络环境来起个名字比如SQL Server 2012 1433。三步做完在另一台机器上用 SSMS 连接服务器IP,端口号试试。如果连不上按这个顺序查先在本机telnet 127.0.0.1 1433确认端口在监听再从外部telnet 服务器IP 1433确认防火墙放行最后检查 SQL Server 自身的登录名和权限。这个分层的排查顺序很关键能帮你快速锁定是网络层、防火墙层还是数据库层的问题而不是瞎试。telnet 127.0.0.1 1433 telnet 192.168.1.100 1433注意开放 1433 到公网是非常危险的做法自动化扫描会持续尝试爆破 sa 账户。远程连接只在内网或者安全组白名单范围内开放公网暴露的场景请通过其他安全机制做访问控制。6. 长期使用中我坚持的几个小习惯装完一个 SQL Server 2012 实例只是开始真正决定这个环境好不好用的是后续的维护习惯。分享几个我自己一直在做的动作。第一件事是装完立刻做一次基线备份。把 master、model、msdb 三个系统库各备份一份连同当前的补丁级别、排序规则、实例配置一起记在一个文本文件里。原因很简单一旦后续因为某个操作把实例搞坏有基线就能对照知道哪些东西变了。我遇到过一次实例无法启动的情况就是靠对比基线发现是某个服务账户被人改了密码。第二件事是把常用的连接方式记下来包括本机连接、IP 连接、命名实例连接三种写法的实际值。很多时候环境是自己装的但过两个月再回来用就忘了实例名和端口。我一般会直接在项目根目录放一个env-note.md记录实例名、端口、sa密码存放位置不存密码本身只存提示、数据目录路径团队协作的时候这份记录能省掉大量沟通成本。第三件事是控制sa的使用范围。我的习惯是给每个应用单独建一个登录名只授予它需要的那几个数据库的权限应用连接串里绝不出现sa。这样即使某个应用的连接串泄露影响面也被限制在它自己的库上。sa只在做实例级维护时临时启用用完就禁用。第四件事是关于老环境的心态。SQL Server 2012 是个成熟的、稳定的老版本把它当学习工具、当兼容测试的靶机非常合适但如果是要长期承载业务就需要正视它已经过了支持周期这个事实。我自己的处理方式是实验环境随便装、随便折腾生产相关的迁移评估尽早启动。最后再补一个小技巧。如果你在虚拟机里装装之前给虚拟机打一个干净的快照装完之后再打一个装好数据库的快照。后续无论装什么新东西导致环境乱掉回滚到装好数据库那个快照只要几十秒比重装一遍快得多。这个习惯帮我在做数据库课程设计辅导的时候节省了大量时间——学生把实例玩坏了回滚一下就好不用等一个小时重装。