SQL Server 2019 内网脱机安装机器学习组件与卡点排查

SQL Server 2019 这套东西，装过的人都知道，常规数据库引擎部分其实半小时就能搞定，真正让人抓头的是微软把机器学习组件（R、Python）从安装介质里拆出去这件事。你可能已经试过：内网机器上挂载 ISO，功能选择页面勾上 Machine Learning Services (In-Database)，顺手把 R 和 Python 也勾了，点"下一步"——然后就没然后了，进度条原地不动，或者弹一句看不懂的提示。我之前在一个完全隔离的内网项目里连着踩了三次，才把整个流程摸清楚。这篇就把 SQL Server 2019 的完整安装步骤、脱机安装 Microsoft 机器学习组件的正确做法，以及"下一步不能继续"这个高频卡点的排查思路，按我实际操作过的顺序完整记录一遍。内容适合正在内网环境部署 SQL Server 2019、准备开机器学习服务做数据建模的朋友，也适合刚接手数据库运维、想把安装这一步打扎实的同学，不管你之前有没有装过 SQL Server，跟着走基本都能复现。

1. 先把安装这件事拆开看：你到底在装什么

1.1 数据库引擎和机器学习组件其实是两套独立的东西

很多人第一次装 SQL Server 2019 会产生一个误解，以为勾选了"机器学习服务"就等于装了个插件。实际上不是这么回事。数据库引擎（Database Engine Services）是安装介质里自带的核心组件，大概 1GB 出头；而 Microsoft 机器学习组件包含了两套完整的语言运行时，一套是基于 Anaconda 发行版的 Python 环境，另一套是 Microsoft R Open / R Server 环境。这两套东西加起来超过 1.5GB，并且它们根本不在 SQL Server 2019 的 ISO 安装介质里。

安装程序在"功能选择"页面被勾上 R 或 Python 之后，会在后台调用独立的组件安装器（RSetup.exe 和 PythonSetup.exe，或者对应的下载引导程序），去微软的下载站点拉取这些运行时包。说得直白点，SQL Server 的 setup.exe 在这里扮演的是一个"包管理器"的角色，它自己不带货，货要去外面取。想清楚这一点，后面所有的现象就都能解释了：内网机器没网，取不到货，进度自然卡住。

注意：这个"外购"行为从 SQL Server 2017 就开始了，2019 沿用同一套机制。所以 2016 及以前能一把装完，2017 之后就得考虑离线源的问题。

1.2 微软为什么要把 R 和 Python 从介质里拆出去

乍一看这是给用户添麻烦，但站在产品迭代角度看，这么做有几个现实理由，理解了之后你也能预判它未来的行为。第一是体积，SQL Server 的 ISO 已经接近 6GB，再塞进去 1.5GB 的语言运行时，安装介质会变得非常臃肿，很多只装引擎的用户白白下载。第二是版本节奏不同步，Python 和 R 的运行时会独立打补丁、独立升级版本，如果打包进 ISO，每次运行时小版本更新都要重新发布整个 SQL Server 介质，成本太高。第三是组件复用，同一台机器上如果装着多个 SQL Server 实例，或者从 2017 升级到 2019，这两套语言运行时可以共用，不需要重复下载。

这些推理不是说微软官方文档逐条这么写的，而是基于它实际发布的组件结构和更新记录，一名装过多次的 DBA 自然会得出的判断。对我们实操的意义在于：既然组件是独立的，那它就可以脱离主安装程序单独安装、单独修复、单独升级。这也是后面脱机方案能成立的根本前提。

1.3 装之前先把版本和授权心里有数

选错版本是新手最常犯的错，装到一半发现功能缺失，重装又得清理一堆注册表残留。SQL Server 2019 主要几个可用版本差异很明确：

自己练手、做 PoC、验证机器学习组件的安装流程，用 Developer 版就够了，功能上跟 Enterprise 完全一致，唯一限制是授权条款不允许上生产。这个坑我见过有人踩：拿 Developer 装了生产库，审计的时候被拎出来。所以选版本这件事，先看用途，再看预算，别一上来就默认全功能。

2. 主程序安装全流程：从挂载 ISO 到实例跑起来

2.1 安装介质准备，别急着点下一步

拿到 ISO 之后，第一步是校验完整性。下载中断、镜像损坏导致的安装失败，排查起来最费时间。用 PowerShell 算一下哈希：

Get-FileHash -Path "D:\SQLServer2019-x64-ENU.iso" -Algorithm SHA256

拿到的结果跟微软下载页面公布的 SHA256 对一遍，一致再动手。

然后是挂载方式的选择，这里有个关键决定。如果你打算后面做脱机机器学习组件安装，建议直接把 ISO 解压到本地目录，而不是用虚拟光驱挂载。原因很直接：脱机方案需要在安装介质的根目录下新建x64\R和x64\Python两个文件夹，把离线 cab 包放进去。虚拟光驱是只读的，你没法往里面写文件。解压出来之后，这个目录既可以当安装源，又可以当离线包目录，一举两得。

# 用 7-Zip 或类似工具解压，或者用 PowerShell 挂载后复制 Expand-Archive -Path "D:\SQLServer2019-x64-ENU.iso" -DestinationPath "D:\SQL2019_Media"

解压完检查一下根目录，应该能看到setup.exe、x64文件夹、resources文件夹这些。看到setup.exe在根目录，就说明介质结构没问题。

2.2 功能选择页面：这几个勾决定了你后面会不会卡

双击setup.exe，进到"安装中心"，选"全新 SQL Server 独立安装或向现有安装添加功能"。前面几页是产品密钥、许可条款、微软更新检查，这些都是常规操作。真正的分水岭在"功能选择"页面。

这里你需要勾的：

• Database Engine Services：必选，数据库核心
• Machine Learning Services (In-Database)：勾上之后会展开 R、Python、Java 三个子项
• 如果你不做报表和 ETL，SQL Server Replication、Full-Text、Data Quality Services 这些可以按需

关键来了：一旦你勾了 Machine Learning Services 下面的 R 或 Python，安装程序在你点"下一步"的时候，就会触发前面说的"外购"行为。所以这个时候你有两个选择：

第一，如果当前机器有外网，让它自己下载，装完再打补丁，这条路最省事但也最看运气，网络抖动一下就可能卡半天。

第二，如果机器在内网完全隔离，千万别在这里跟着感觉走，因为只要你勾了，点下一步大概率卡住。正确做法是先去把离线包准备好，放到位，再回来勾，这样安装程序检测到本地已有文件，就不会再联网了。具体怎么准备，第 4 章会完整展开。

提示：Java 语言扩展是 SQL Server 2019 才引入的，勾选后需要指定 JRE 路径。它默认依赖 Azul Zulu OpenJDK，如果你机器上已经装了标准 JDK，需要留意版本兼容性，别在两个 JDK 之间把环境变量搞乱。

2.3 实例配置、服务账户和身份验证，一步错后面全是坑

过完功能选择，接下来几页如果随手点，后期运维会很难受。逐个说。

实例配置：默认实例（MSSQLSERVER）还是命名实例，取决于你一台机器上要装几个 SQL Server。如果只装一个，用默认实例最省心，连接时不用带实例名。如果已经有一个旧实例，那必须用命名实例，不能重名。

服务账户：这一步很多人直接跳过用默认值。默认情况下，SQL Server 各服务会用内置的虚拟账户，比如NT Service\MSSQLSERVER。这种方式安全性好，不需要密码，也符合最小权限原则。只有当你的数据库需要访问网络共享、或者要跟域环境集成做备份、链接服务器时，才考虑换成域账户。换成域账户记得提前把 SPN 注册好，否则后面 Kerberos 认证会出问题。

身份验证模式：一定选混合模式（SQL Server 和 Windows 身份验证），并给 sa 设置一个强密码。纯 Windows 模式虽然更安全，但一旦你的 Windows 账户出问题，或者需要从非域机器连过来，就会直接进不去。混合模式是留了一条后路的做法。

数据目录规划：这是我最想强调的一步。默认安装会把数据、日志、备份、临时库全部塞到 C 盘，生产环境这是灾难。合理的做法是分盘：

这些目录最好在安装前就建好，并给服务账户授予完全控制权限。装完再迁移会很麻烦。

2.4 装完先做这几项验证，别等出问题再回头

安装程序跑完，看到"成功"两个字别急着关。先做四项检查，确认实例真的活着。

第一，打开"服务"管理器，看SQL Server (MSSQLSERVER)和SQL Server 代理 (MSSQLSERVER)是否处于运行状态。代理默认可能是手动启动，需要手动开启。

第二，用 SSMS 或者 Azure Data Studio 连一下，执行：

SELECT @@VERSION;

应该返回类似 "Microsoft SQL Server 2019 (RTM-CUxx) ..." 的字符串。如果连不上，先看 TCP/IP 协议有没有启用，再看防火墙 1433 端口。

第三，在命令提示符里确认端口监听：

netstat -ano | findstr :1433

有 LISTENING 才说明实例在正常接收连接。

第四，检查错误日志有没有异常。日志位置：

C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Log\ERRORLOG

里面如果有大段的 "Login failed" 或者 "The SQL Server Network Interface library could not register the Service Principal Name"，就要及时处理。

3. 脱机装机器学习组件卡住"下一步"的真实原因

3.1 安装程序在你看不见的后台做了什么

点了"下一步"之后，界面只是短暂停顿，但后台其实发生了好几件事，理清楚这个链条，你才知道为什么它卡住。

第一步，setup.exe 解析你勾选的机器学习组件，识别出需要 R 和（或）Python 运行时。

第二步，它把这部分工作交给独立的子安装器：R 组件走 RSetup，Python 组件走 PythonSetup。

第三步，子安装器会先检查本地有没有可用的离线包，比如安装介质x64\R、x64\Python目录下的 cab 文件。如果没有找到，它就去微软的下载服务器拉取。

第四步，这个拉取动作需要完整的网络链路：DNS 解析、TLS 握手、HTTP 下载。内网机器如果连 DNS 都出不去，这里就会一直重试或超时。界面上表现出来的就是"下一步"按钮变灰、进度条卡住、或者干脆整个窗口无响应。

所以"下一步不能继续"不是安装程序坏了，是它在等一个永远不会来的网络响应。

3.2 三种典型卡顿表现，对应不同的根因

根据我遇到的和同行反馈的情况，这个卡点大致分三类：

第三类里有个隐蔽情况：有些内网虽然能出网，但只放通了 80 端口，而微软的下载走 HTTPS（443），或者要求 TLS 1.2 而老系统只开了 TLS 1.0，结果一样是失败。这种时候你会觉得"明明能上网为什么不行"，其实就是 TLS 层面的问题。

3.3 复制 ISO 到内网机器为什么不管用

这是最典型的误区。很多人第一反应是把整个 SQL Server ISO 拷到内网机器上，觉得组件就在里面。不在。ISO 里只有引擎、SSAS、SSIS、SSRS 这些，R 和 Python 的运行时是独立 CDN 分发的。你就算把 ISO 复制十份也没用，安装程序照样会去联网找。

真正要复制的是那些独立的离线组件包。这些包微软是单独提供下载的，文件名有固定的命名规律，下面一章会讲怎么找、怎么放。

4. 脱机安装机器学习组件的完整实操

4.1 先把离线包准备好，放到安装介质的正确目录

这一步是整篇的核心，做对了后面就是一路顺风。

首先，在一台能上网的机器上，去微软官方的下载中心找到 SQL Server 2019 对应的 R 和 Python 离线组件包。以 SQL Server 2019 RTM 为例，这两个包的文件名大致是SRO_3.5.2.cab（R 运行时）和SPO_4.5.2.cab（Python 运行时）这种形式，具体的小版本号会随累积更新变化，一定要以你下载时官方页面标注的版本为准。如果找不到，可以在 SQL Server 安装包下载页面的"附加组件"或"Machine Learning Services 脱机安装"相关章节里翻，或者在微软的 Download Center 搜关键词。

拿到两个 cab 文件后，回到那台内网机器的 SQL Server 安装介质目录（就是你前面解压出来的D:\SQL2019_Media），在根目录下创建两个文件夹：

D:\SQL2019_Media\x64\R\ D:\SQL2019_Media\x64\Python\

把 R 的 cab 放进x64\R，Python 的 cab 放进x64\Python。注意不要改名，安装程序是按文件名前缀识别的，改了名字它可能就认不出来。

注意：目录层级一定是x64\R和x64\Python，不是x64\MachineLearning\R。这个路径是安装程序的硬编码查找位置，写错了它照样联网。

4.2 重新跑安装，或者用命令行静默装

准备工作做完，回到安装程序。这时候你有两种路径。

路径一：GUI 重装。如果之前那次卡住了，先正常退出安装程序，把失败的安装记录清理掉，重新运行setup.exe，走到功能选择页，勾上 Machine Learning Services 和 R/Python，点下一步。这次因为本地目录里有包，安装程序会跳过下载，直接本地解压安装。整个环节通常几分钟就能过。

路径二：命令行静默安装。适合批量部署或者脚本化场景。核心功能参数是ADVANCEDANALYTICS，一个简化示例如下：

setup.exe /Q /ACTION=Install /FEATURES=SQLENGINE,ADVANCEDANALYTICS ^ /INSTANCENAME=MSSQLSERVER /SQLSVCACCOUNT="NT Service\MSSQLSERVER" ^ /SQLSYSADMINACCOUNTS="BUILTIN\Administrators" ^ /IACCEPTSQLSERVERLICENSETERMS

注意这里的^是 Windows 命令行的续行符。如果用 PowerShell 写脚本，换成反引号`。参数里的账户、路径都要按你实际环境替换。命令行安装之前，务必先在测试机上把参数跑通再上生产，静默安装失败时的日志排查比 GUI 麻烦。

4.3 装完立刻验证，别等业务上来才发现问题

组件装完，用一段 T-SQL 直接测试外部脚本能不能跑：

EXEC sp_execute_external_script @language = N'Python', @script = N' result = 1 + 1 print("Python 扩展运行正常，结果为:", result) ';

执行成功会返回一行输出。如果报错，常见的有：

• "外部脚本已禁用"：需要开启配置项
• "无法启动 SQL Server Launchpad 服务"：服务没起来或者账户权限不够

开启外部脚本的配置命令：

EXEC sp_configure 'external scripts enabled', 1; RECONFIGURE WITH OVERRIDE;

改完需要重启 SQL Server 实例才生效。这一点特别容易被忽略，很多人改完没重启，一直报错以为是自己装错了。

另外去文件系统里确认一下 Python 环境目录确实生成了：

C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\PYTHON_SERVICES

这个目录里有python.exe和一堆 site-packages，说明 Python 运行时是真的落盘了。R 对应的是R_SERVICES目录。

4.4 累积更新（CU）打完之后组件可能"消失"

这是另一个隐藏坑。SQL Server 2019 从 RTM 到后面的累积更新，版本一路在升。如果你先装 RTM 再打 CU，某些 CU 会重新触发机器学习组件的安装流程。如果这时候你的离线包目录还在、还在原位，那没问题；如果你打完补丁把介质删了，CU 安装到这里又会卡住——同样的原因，它又要去联网找包。

所以我的建议是：离线组件包和解压后的安装介质，长期保留一份在内网文件服务器上，别用完就删。另外如果要把 RTM+CU 一次性装完，更省事的做法是使用微软提供的、已经集成好最新 CU 的安装介质（SQL Server 安装中心里叫"Slipstream"或"集成更新"的方式），这样组件版本一次到位，不用二次折腾。

5. 安装日志与常见问题速查

5.1 日志到底在哪，怎么读才不浪费时间

安装出问题，第一反应不该是重装，而是看日志。SQL Server 安装日志的根目录是：

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

里面有一个Summary.txt，是所有安装动作的概览，先看它，找 "Failed" 或者 "Error" 关键词，定位到失败的那一步。深入到具体的时间戳子目录里，Detail.txt是最详细的执行记录，机器学习组件相关的错误通常能在这里看到下载 URL 和具体的错误码。

除了主日志，R 和 Python 子安装器还会在自己的安装目录或者临时目录留下日志，比如RSetup.log、PythonSetup.log。这些文件里会明确写出它尝试访问了哪个地址、为什么失败。定位卡点的时候，看到这些地址就能一眼确认是不是网络问题。

5.2 高频报错和处理对照

把最常见的几个问题整理成表，按现象查原因，能省不少时间：

这张表里前三行的处理办法是同一个：脱机。这也从侧面说明，在内网环境里，脱机安装不是可选项，是必选项。

5.3 我自己踩过的坑，顺手记一下

坑一：以为杀进程重来就行。卡住的时候直接结束 setup.exe 进程，结果安装状态没清理干净，第二次运行提示"已存在挂起的安装操作"，还得手动去清注册表里的 PendingFileRenameOperations。正确做法是让它正常超时退出，或者用安装中心的"修复"功能走一遍。

坑二：把 cab 放错层级。我一开始放在SQL2019_Media\MachineLearning\下面，结果安装程序完全无视，照样联网。后来翻日志才发现它只认x64\R和x64\Python。

坑三：只勾父项不勾子项。Machine Learning Services (In-Database) 勾上之后，R 和 Python 是单独的子复选框。我第一次只勾了父项，以为默认包含，结果装完啥都没有。这个细节一定要看清楚。

坑四：装完忘了重启。开启 external scripts enabled 之后没重启实例，测试报错，以为是安装失败，来回查了两个小时，最后发现就差一次重启。别笑，这个坑很常见。

6. 装完之后：基础加固与后续维护

6.1 服务、端口和账号做最小化配置

SQL Server 装完默认开启的服务不少，生产环境按需裁一遍。比如 SQL Server Browser、某些诊断服务，如果业务用不到，可以停掉并改为手动启动，减少攻击面。端口方面，默认 1433 如果暴露在公网可达范围，建议改端口或者用防火墙做白名单限制。SQL Server 配置管理器里的"SQL Server 网络配置"可以关掉不需要的协议，只留 TCP/IP。

账号权限上，sa 账户不要日常使用，建一个专用的管理账号，按角色授权。机器学习服务相关的 Launchpad 服务账户，保持默认的虚拟账户就好，别为了"方便"改成 Administrator。

6.2 备份和维护计划，装完就该建

数据库刚装完是最干净的时候，也是建备份策略的最佳时机。至少一个完整备份 + 差异备份 + 事务日志备份的组合，备份文件不要放在跟数据文件同一个物理盘上。SQL Server 代理里配置维护计划，或者用 Ola Hallengren 那套脚本，把索引重建、统计信息更新、完整性检查这些固定下来。

TempDB 的配置也值得单独提一句。默认单文件、自动增长，高并发下容易有争用。合理做法是按 CPU 核数配多个等大小的数据文件（一般不超过 8 个），并且设置固定大小避免频繁增长。

6.3 机器学习服务后续还能怎么扩展

装好 Python 和 R 之后，这套环境可以做的事就多了。数据库内直接跑 Python 脚本做数据清洗、特征工程、调用 scikit-learn 训练模型，结果直接落回表里，省去了数据搬运。SQL Server 2019 还支持 Java 扩展，可以用 Java 写自定义的扩展程序复用到数据库里。如果后面要上生产级的模型服务，还可以考虑把训练好的模型通过 PREDICT 函数做批量推理。这些事情的前提，都是安装这一步没有踩坑、组件是真的装全了。

我个人在实际操作中的体会是，内网环境装 SQL Server 2019 加机器学习组件，"脱机准备"这四个字要提前想，不能等到卡住了才回头。安装介质解压到本地、cab 包提前放到位、配置文件路径提前规划好，这三件事做完，整个安装过程就顺得像装个普通软件。反过来，如果抱着"先装着看看"的心态，卡在"下一步"的时候再去找包，时间成本至少翻三倍。最后再分享一个小习惯：每次装完，把当时的安装介质目录、cab 包版本号、CU 版本、执行的配置命令，整理成一份内部文档存好。等半年后要给另一台机器装，或者要给领导解释环境的时候，你会感谢当时的自己。