navicat链接sqlserver

Navicat 连 SQL Server，十次里有八次卡在驱动上。不是 Navicat 本身有问题，是微软那套认证机制和默认端口配置在作怪。我上周帮同事调一个本地实例，折腾了四十分钟，最后发现是 SQL Server Browser 服务没启动——这种坑，官方文档不会主动告诉你。

先确认你装的是 Navicat Premium 或 Navicat for SQL Server。普通版 Navicat 不带 SQL Server 驱动，连不上就是连不上，别浪费时间。打开 Navicat，点“连接”选 SQL Server，弹出来的窗口里，主机名填 IP 或 localhost。如果你连的是默认实例，端口写 1433；命名实例就写实例名，比如 SQLEXPRESS，端口留空让 Navicat 自己找。但这里有个前提：SQL Server Browser 服务必须开着，否则命名实例根本广播不出去。很多人只启动 SQL Server 主服务，Browser 服务是手动或禁用状态，Navicat 自然找不到实例。

认证方式分两种。SQL Server 身份验证最省事，填 sa 账号和密码就行。但 sa 默认可能是禁用的，得去 SSMS 里启用，顺便设个强密码。Windows 身份验证稍微绕一点，Navicat 会拿当前 Windows 登录凭证去连，适合域环境。我自己的习惯是用 SQL Server 验证，跨平台迁移时少很多麻烦。如果你选 Windows 验证却报“登录失败”，先确认 Navicat 是不是以管理员身份运行的——UAC 会拦截凭证传递，这个细节很少有人提。

驱动问题更隐蔽。Navicat 自带 SQL Server 驱动，但版本可能偏旧。连 SQL Server 2019 或 2022 时，如果报 SSL 相关错误，比如“证书链由不受信任的颁发机构颁发”，别急着换驱动。去“高级”选项卡里把“使用加密”关掉，或者勾上“信任服务器证书”。生产环境当然不该这么干，但本地开发图个方便，先连上再说。我见过有人为了这个错误重装了三遍 Navicat，其实改个勾选就完事。

防火墙也是常客。Windows 防火墙默认拦 1433 入站，尤其你从另一台机器连过来的时候。快速测试：在目标机器上 telnet 127.0.0.1 1433 通不通。不通就去“高级安全 Windows Defender 防火墙”里加个入站规则，开放 TCP 1433。命名实例还动态分配端口，更麻烦，干脆在 SQL Server 配置管理器里把 TCP/IP 的 IP 地址选项卡拉到底，把“TCP 动态端口”清空，手动指定一个固定端口，比如 1433，然后重启服务。

连上之后别急着关窗口。Navicat 左侧列表里右键连接，选“编辑连接”，点“测试连接”确认状态。我习惯再开个查询窗口跑 SELECT @@VERSION，看到版本号才算真正通了。有时候测试连接成功，但实际查询报错，多半是数据库默认架构或权限问题，跟连接本身无关。

最后说个冷门情况：SQL Server 装了 TLS 1.2 补丁后，旧版 Navicat 的驱动可能握手失败。升级 Navicat 到最新版，或者去微软官网下个 ODBC Driver 17 手动替换。别用 18，18 对旧实例兼容性反而差。这些经验都是踩出来的，文档里翻不到。