Spring AI 2.0 RAG优化实战：Chunking、混合检索与Rerank的优先级与配置
2026/9/25 4:26:48
搞数据库的人大概都遇到过这个场景：开发环境里 SQL Server 跑得好好的，本地写查询一点问题没有，可一拿到内网里另一台电脑上，要么连不上，要么弹出各种奇怪的证书报错。其实“SQL Server 数据库可以在内网连接访问”这句话本身没有错，但它背后藏着四个必须打通的环节——服务端监听、网络放行、身份验证、证书信任。任何一环没搞定，你看到的都是“无法连接”。这篇文章把我从零配置内网访问的完整经验写出来，包含服务端配置、客户端连接字符串、常见报错排查，适合刚接触 SQL Server 的运维和开发，也适合那些在公司内网环境里被连接问题折腾了一天的朋友。
1. 内网连接访问的整体思路：别急着改配置，先搞懂四层链路
很多教程一上来就让你改 SSMS 的服务器名称，或者给 sa 账号设密码，但大多数连接失败的根本原因是链路没通。我习惯把内网访问拆成四层，挨个检查。
1.1 SQL Server 是否真正在监听网络
SQL Server 不是默认“站在门口等你”的。它装好之后，到底监听哪个端口、走什么协议，是由 SQL Server 配置管理器（SQL Server Configuration Manager）里的“SQL Server 网络配置”决定的。常用的协议有 Shared Memory（本机进程通信）、Named Pipes（命名管道）、TCP/IP（真正的网络协议）。内网访问必须走 TCP/IP，可很多机器 TCP/IP 是禁用的，或者启用了但监听的端口不对。这个问题在低版本上更隐蔽，因为低版本安装时默认值可能跟你想的不一样。所以第一步永远不是去客户端折腾，而是先到服务端确认：TCP/IP 到底开没开，监听端口是不是 1433 或你自己指定的那个。
1.2 网络路径与防火墙是否放行
就算 SQL Server 在监听，操作系统防火墙、硬件防火墙、路由器 ACL 也可能把包拦在半路。内网不等于没有防火墙。Windows 的入站规则默认不会给 SQL Server 放行 1433，你新装实例后不手动加规则，其他机器就是过不来。判断网络是否可达最直接的办法，是拿 telnet 或 PowerShell 的 Test-NetConnection 去敲服务器的 IP 和端口，能通再继续往下查，不然后面全是白忙。
1.3 身份验证模式是否允许远程登录
TCP 通了之后，数据库本身还要认你这个登录名。SQL Server 安装时可以选 Windows 身份验证或混合模式。如果选的是 Windows 身份验证模式，你用 sa 或者自定义 SQL 账号登录，哪怕密码正确，也会报 18456。内网机器加域的环境里用 Windows 身份验证很方便，但如果客户端没加域、或者你不是用域账号跑客户端，老老实实开混合模式，启用 SQL Server 身份验证，才是省事的办法。
1.4 加密与证书是否匹配
这是近几年特别容易踩的坑。新版 SQL Server 默认启用强制加密或带自签名证书，而新版的客户端驱动（比如 ODBC Driver 17/18、某些版本的 JDBC）默认又要求校验 SSL 证书。两边一撞，就会出现“证书链是由不受信任的颁发机构颁发的”这类报错。记住一个原则：开发环境或内网环境里，要么在连接串里显式加上信任自签名证书，要么在服务端安装受信任的 CA 证书，二选一，否则永远连不通。
2. 服务端关键配置：在 SQL Server 配置管理器里把五件事做对
服务端配置是整个内网连接的源头。我按实际操作顺序整理成五步，每一步都有对应的验证方式。
2.1 启用 TCP/IP 并固定端口
打开 SQL Server 配置管理器（开始菜单里搜 SQL Server Configuration Manager，如果装了 SQL Server 2022 但没找到，可以去 Windows 的“计算机管理”里看，或者从 Microsoft 官网单独下载对应版本的管理工具），然后依次展开“SQL Server 网络配置”，点击对应实例，比如“MSSQLSERVER”。右侧列表里能看到 Shared Memory、Named Pipes、TCP/IP 三项。
双击“TCP/IP”，切到“IP 地址”标签页。这里要关注两栏：一是“IPAll”下面的“TCP 动态端口”，如果里面有数字，说明实例用的是动态端口，客户端不好连接；二是“IPAll”下的“TCP 端口”，一般设成 1433。把动态端口里的数字清空，固定端口写上 1433，或者你内网规划的自定义端口。改完后重启 SQL Server 服务，配置才生效。
重启服务可以在配置管理器左侧“SQL Server 服务”里右键实例选“重启”，也可以用命令行：
net stop MSSQLSERVER net start MSSQLSERVER注意如果实例名不是默认实例，服务名会变成类似 MSSQL$SQLEXPRESS 的形式。
2.2 防火墙放行 1433 端口
服务端配置好后，下一步就是给防火墙开门。Windows 防火墙操作路径是：控制面板 → Windows Defender 防火墙 → 高级设置 → 入站规则 → 新建规则。规则类型选“端口”，协议选“TCP”，本地端口填 1433，操作选“允许连接”。如果你担心公网暴露，可以把作用域限制成内网网段，比如只允许 192.168.1.0/24 访问，这样即使端口开着，外网也够不着。
还有一种情况是服务器上有第三方安全软件，比如 360、火绒之类，这些软件自带网络防护，可能会拦截入站流量。所以加了 Windows 规则后，如果还连不上，记得看一眼安全软件有没有拦截日志。
2.3 开启混合验证模式并启用 sa 账号
在 SSMS 里连上服务器，右键服务器节点选“属性”，切到“安全性”页，把“服务器身份验证”改成“SQL Server 和 Windows 身份验证模式”。这一步做完最好重启一下 SQL Server 服务，否则某些情况下不会马上生效。
sa 账号在安装完之后默认是禁用的。用 SSMS 的“安全性 → 登录名 → sa”进去，先把密码改成强密码，然后右键 sa 选“属性”，在“状态”页里把“启用”勾上。更直接的方式是执行 T-SQL：
ALTER LOGIN [sa] WITH PASSWORD = '你的强密码'; ALTER LOGIN [sa] ENABLE;这里给个忠告：sa 是超级管理员账号，哪怕在内网也别用弱密码。我见过不止一次企业内部库被扫库工具扫到，起因就是 sa 密码设置成了简单数字。内网不等于安全，这点意识必须有。
2.4 高版本 SQL Server 的加密与证书策略
前面说过新版驱动的证书校验问题。在服务端，SQL Server 2019、2022 默认会生成自签名证书，并对连接启用“强制加密”策略。你可以打开 SQL Server 配置管理器，右键“SQL Server 网络配置”下的“协议”，选“属性”，在“标志”页里看到“Force Encryption”，如果设成了“是”，那所有连接都必须走 SSL 加密，客户端必须信任服务端证书。
处理办法有两种：一是保持 Force Encryption = 是，然后给 SQL Server 配置一个企业 CA 签发的正式证书，让客户端能通过证书链验证；二是内网环境图省事，把 Force Encryption 设成“否”，等客户端报证书错误时，在连接串里写 TrustServerCertificate=True。记住：这是两个层面的东西，服务端强制加密 + 客户端信任自签名证书，这才是常见的内网标准组合。
2.5 实例服务重启与验证
配置改完后，右击实例选“重启”。重启之后用服务端本机检查端口是否在监听：
netstat -ano | findstr 1433看到 LISTENING 状态，说明 SQL Server 已经开始在 1433 端口上接收连接了。这步一定要做，因为有时候你改了 TCP/IP 配置但忘了重启，服务还跑在老配置上，客户端依然是“找不到实例”或者“连接超时”。
3. 客户端连接配置与连接字符串速查
服务端通了，客户端这边同样有细节。很多人卡在“服务器名称怎么填”“连接串怎么写”这两个问题上。
3.1 SSMS 连接参数：服务器名称的写法
打开 SSMS，第一行“服务器名称”里，不是你随便填个 IP 就能通的。最常用的三种写法是：
| 写法 | 适用场景 | 示例 |
|---|---|---|
IP,端口 | 明确使用 TCP 端口连接，最稳定 | 192.168.1.10,1433 |
主机名\实例名 | 连接命名实例，依赖 SQL Browser 服务 | WIN-SERVER\MSSQLSERVER |
IP\实例名,端口 | 同时指定实例和端口，更精确 | 192.168.1.10\MSSQLSERVER,1433 |
我的建议是：能写 IP 加端口就写 IP 加端口，别依赖实例名解析。命名实例的端口解析需要 SQL Server Browser 服务（UDP 1434）配合，内网环境里很多人没开这个服务，或者防火墙把 UDP 1434 挡了，你会看到一个很普通的“服务器找不到”错误，实际原因是解析动态端口失败了，非常冤枉。
身份验证这一块选“SQL Server 身份验证”，输入 sa 和密码。如果你是域环境，也可以选“Windows 身份验证”，前提是服务端开着 Windows 验证模式，且客户端有权限。
3.2 编程语言的连接字符串：直接抄作业
内网连接最终往往要落到代码里。下面三类连接串我实测过，只要服务端配置对了，复制粘贴就能用。
C# / .NET：
Server=192.168.1.10,1433;Database=你的库名;User Id=sa;Password=你的密码;TrustServerCertificate=True;Encrypt=True;Python（pyodbc）：
import pyodbc conn_str = ( "DRIVER={ODBC Driver 17 for SQL Server};" "SERVER=192.168.1.10,1433;" "DATABASE=你的库名;" "UID=sa;PWD=你的密码;" "TrustServerCertificate=yes;" ) conn = pyodbc.connect(conn_str)Java（JDBC）：
String url = "jdbc:sqlserver://192.168.1.10:1433;" + "databaseName=你的库名;" + "encrypt=true;trustServerCertificate=true;" + "user=sa;password=你的密码;";重点解释一下TrustServerCertificate=True的作用：它表示客户端不去校验服务器证书是否由受信任的 CA 签发，直接用服务器提供的自签名证书完成加密。对应的就是热词里经常出现的“证书链不受信任”那个报错，加上它基本就能消掉。
3.3 命令行验证：不装图形工具也能连
有些服务器没装 SSMS，只用 sqlcmd 就够了。命令格式很直白：
sqlcmd -S 192.168.1.10,1433 -U sa -P 你的密码 -Q "SELECT @@VERSION"如果只想测试端口通不通，用 PowerShell：
Test-NetConnection 192.168.1.10 -Port 1433TcpTestSucceeded 返回 True，说明网络层没问题。这比开 SSMS 慢慢试快得多，我排查问题从来都是先跑这条命令。
4. 实操全流程：从零到连通的完整记录
前面把原理和零散配置讲清楚了，这一节给一个完整流程，方便你照着操作。
4.1 确认当前服务器状态
登录数据库服务器，打开服务管理器（Win + R，输入 services.msc），找到“SQL Server (MSSQLSERVER)”，确认状态是“正在运行”。然后打开命令提示符：
netstat -ano | findstr 1433没有输出就说明没监听，回头查 TCP/IP 配置。这一步是“现状确认”，能帮你少走很多弯路。
4.2 修改 SQL Server 网络配置
打开配置管理器，依次完成：
- 展开“SQL Server 网络配置” → 选中实例。
- 启用 TCP/IP（右键选择“启用”）。
- 双击 TCP/IP，在“IP 地址”标签页里把 IPAll 下的“TCP 动态端口”清空，写上“TCP 端口”= 1433。
- 到“SQL Server 服务”里重启实例。
注意：不要试图把“IP 地址”下面所有条目都填一遍，绝大多数场景只需要设置 IPAll 这一层。手动给每个具体 IP 填端口反而容易造成监听混乱。
4.3 放通防火墙入站规则
按前文提到的方法，在 Windows 防火墙里新建入站规则，放行 TCP 1433。你还可以顺便放行 UDP 1434，这是给命名实例用的 SQL Browser 解析端口，以防以后要连命名实例。加完后用客户端机器跑一次：
Test-NetConnection 192.168.1.10 -Port 1433通了，继续；不通，检查服务器的 IP 地址是不是 192.168.1.10，或者中间有没有硬件防火墙。
4.4 启用 sa 与混合验证模式
用本机 SSMS 登录，执行：
EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'LoginMode', REG_DWORD, 2; GO ALTER LOGIN [sa] WITH PASSWORD = '强密码'; ALTER LOGIN [sa] ENABLE; GOLoginMode=2就是混合验证模式的注册表写法，省得一次次去界面里勾选。执行完重启 SQL Server 服务。
4.5 客户端正式验证
在另一台电脑上打开 SSMS，服务器名称填192.168.1.10,1433，身份验证选“SQL Server 身份验证”，用户名 sa，输入密码，点连接。正常情况下会直接进入对象资源管理器，能看到实例下的所有数据库。如果在这里还报错，多半就是证书问题，跳到第 5 章看排查方法。
5. 常见报错与排查实录
互联网上关于 SQL Server 内网连接的报错，来来回回就那么几类。我按出现的频率整理成速查表，再展开讲最麻烦的 SSL 证书问题。
| 报错信息 | 大概率原因 | 解决办法 |
|---|---|---|
| 证书链由不受信任的颁发机构颁发（-2146893019） | 客户端校验服务端自签名证书失败 | 连接串加 TrustServerCertificate=True |
| 客户端无法建立连接（-2146893019） | 网络不通或证书问题 | 先测端口连通性，再查证书配置 |
| 用户 x 登录失败（错误 18456） | 密码错误 / 账号禁用 / 非混合验证模式 | 启用 sa，设置强密码，切换验证模式 |
| 在连接到 SQL Server 时，TCP 端口 1433 被拒绝 | 防火墙未放行服务端端口 | 添加防火墙入站规则 |
| 找不到实例 / 无法解析服务器名称 | 命名实例动态端口没解析 | 改用 IP,端口 形式，或启动 SQL Browser |
| 驱动程序无法通过 SSL 加密建立安全连接 | 服务端强制加密，客户端不信任证书 | 服务端装正式证书，或客户端信任自签名证书 |
5.1 SSL 证书链报错：-2146893019 的完整解法
常见的报错原文是这样的：
[08001] [Microsoft][ODBC Driver 17 for SQL Server]SSL 提供程序: 证书链是由不受信任的颁发机构颁发的。(-2146893019) [08001] [Microsoft][ODBC Driver 17 for SQL Server]客户端无法建立连接 (-2146893019)我最早见到这个报错是在 2021 年，当时把 ODBC 驱动从 13 升到 17，旧连接串直接全部不能用了。原因很简单：新版驱动默认对服务器发来的自签名证书进行校验证书链，而 SQL Server 默认用的就是自己签发的证书，自然不在系统受信任的根证书列表里，于是客户端认为“证书不可信”，拒绝建连。
解法优先级如下：
- 在连接串中加入
TrustServerCertificate=True或TrustServerCertificate=yes。这是最快、最适配内网开发环境的方式。 - 如果你用的是 ODBC DSN 方式，去“ODBC 数据源管理器”里的“连接”页，勾选“信任服务器证书”。
- 长期、生产环境，正确做法是给 SQL Server 安装正式证书：在配置管理器实例属性里的“证书”页签，导入受信任 CA 签发的证书，然后开启 Force Encryption。
不要在服务端把 Force Encryption 设为“否”来逃避问题，这会让数据库连接以明文方式在网络上传输。内网环境里虽然相对安全，但只要有人做了抓包，你的数据库账号密码和业务数据就全暴露了。
5.2 错误 18456：sa 无法登录
18456 几乎是 SQL Server 登录失败的标准报错。大多数人第一个反应是“密码错了”，但其实后面还有“状态码”可以看。
| 状态码 | 含义 |
|---|---|
| 18456 | 一般性登录失败 |
| 18456, 状态 1 | SQL Server 服务登录该账号的信息有问题 |
| 18456, 状态 2 / 5 | 账号被锁或被禁用（最常见） |
| 18456, 状态 8 | 密码不正确 |
| 18456, 状态 9 | 密码过期或者必须更改 |
如果是状态 2/5，去 SSMS 里把 sa 账号启用；状态 8 就重置密码；状态 9 执行ALTER LOGIN sa WITH CHECK_EXPIRATION = OFF关掉密码过期策略，再重新设置强密码。注意：内网里面为了让密码策略不捣乱，可以统一关掉强制过期，但密码复杂度别降。
5.3 端口不通：Telnet 和 netstat 组合排查
如果Test-NetConnection显示 TcpTestSucceeded 为 False，问题肯定在网络层，跟 SQL Server 无关。这时按顺序查：
- 服务器本机执行
netstat -ano | findstr 1433，确认端口处于 LISTENING 状态。 - 客户机上执行
ping 192.168.1.10，确认能通；如果 ping 不通，检查 IP 和交换机配置。 - 检查 Windows 防火墙入站规则是否存在并已启用。
- 用服务器本机再执行
telnet 127.0.0.1 1433，通了说明服务没问题，问题在防火墙或网络路径。
5.4 命名实例连不上的坑：SQL Browser 服务
内网环境里很多人喜欢写“服务器名\实例名”，比如192.168.1.10\MSSQLSERVER。如果默认实例倒也还好，但命名实例依赖 SQL Server Browser 服务通过 UDP 1434 解析端口。很多精简系统默认把 Browser 服务禁用了，或者防火墙没放行 UDP 1434，于是客户端拿着实例名到处问“这个实例在哪个端口”，没人回答，最终报错。
最稳妥的做法就是不依赖实例名，直接查清楚端口后写IP,端口。动态端口本身就不好维护，建议在生产环境固定端口，省心。
5.5 其他工具类报错的共性
热词里出现的 SolidWorks Electrical 无法连接 SQL Server、Excel 导入数据库报错等问题，本质上都是同一个模型：某个客户端工具，拿着它自己的连接配置去连 SQL Server 的内网实例。排查思路永远是：
- 确认工具要求的服务器名、实例名、端口写法。
- 在工具的本机环境里验证
Test-NetConnection。 - 用最小的手段（sqlcmd / SSMS）确认数据库账号能登录。
- 再去改工具的连接配置。
不要一上来就重装工具或重装 SQL Server，大概率是配置细节没对上。
6. 内网连接之外的高频场景：同步、备份、批量配置
连接打通之后，很多衍生需求也会接连出现。数据库同步、备份还原、多机批量配置，这些场景里藏着不少坑。
6.1 数据库同步与高可用
数据库同步工具不一定是第三方软件，SQL Server 本身就支持发布订阅（Replication）、镜像、Always On 可用性组。无论哪种方案，它们都依赖数据库实例之间的网络互通。做内网同步时，除了 1433 端口，还要特别关注端点端口、UDP 1434 以及 Windows 防火墙对多播广播的放行情况。我见过一个同步作业每天凌晨失败，排查了很久才发现是备用服务器防火墙规则里只放了 1433，没放镜像端点端口，流量被静默丢弃，同步自然时断时续。
6.2 备份还原与版本兼容
热词里有个“sql server 2012的数据库备份2008能用吗”类似的问题，这类“版本向下兼容”问题跟连接不太一样，但影响很现实。你从高版本备份的 .bak 文件，低版本实例是不能直接还原的，因为物理结构不兼容。反过来说，低版本备份还原到高版本一般没问题。如果你在做跨版本迁移或内网多机同步，先用DBCC CHECKDB检查源库完整性，再按目标版本实际测试还原，别丢到生产机上才发现报错。备份文件在内网里传输本身不依赖 SQL Server 端口，但如果你用的是共享文件夹，反而要注意系统账户的共享权限，这是一个容易被忽略的“假连接问题”。
6.3 多台机器批量配置的小技巧
如果你要管理十几台 SQL Server，挨个用 SSMS 图形界面配置太慢了。我实际操作中最常用的做法是先配置好一台模板机，然后把关键信息提取成脚本，用下面的思路批量执行：
- 记录模板机的注册表
LoginMode值和 TCP/IP 配置位置。 - 用 PowerShell 脚本批量检测每台机器的 1433 端口监听情况。
- 通过远程 PowerShell 或配置管理器接口统一修改 TCP/IP 状态和防火墙规则。
但注意不要盲目复制注册表值，因为实例名称不同时，注册表路径里的MSSQL16.MSSQLSERVER会不一样，复制前先核对实例路径，避免改到别的实例上。
我在实际项目里最常遇到的情况，不是 IP 地址写错，也不是防火墙没开，而是很多人把 SQL Server 当作“装好就能远程连”的软件，完全忽略了服务端 TCP/IP 可能被禁用、sa 默认被禁用、新版驱动默认校验证书这三件套。内网连接访问 SQL Server 这件事，配置链路并不复杂，只要把服务端监听、网络放行、账号验证、证书信任四个环节逐一确认，基本都能通。最后顺手再分享一个排查习惯：每改完一处配置，都立刻用Test-NetConnection和 sqlcmd 做一次最小化验证，而不是直接打开完整的 SSMS 去看图形界面。这个习惯能帮你把“配置错误”和“网络故障”快速区分开，节省大量排查时间。