ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

Navicat连接SQL Server全流程:选型、配置、排错与数据同步

Navicat连接SQL Server全流程:选型、配置、排错与数据同步 1. 先把选型和授权说清楚Navicat 管 SQL Server 到底合不合适1.1 Navicat 在这个组合里干的活Navicat 和 SQL Server 这一对组合在国内的开发、运维和数据分析圈子里出现频率非常高。原因很简单SQL Server 自带的管理工具 SSMSSQL Server Management Studio功能足够强但它的定位是面向 DBA 的重型工具装一次几百兆到几个 G启动慢界面偏工程化而 Navicat 的定位是轻量、跨库、顺手一个客户端能同时挂 MySQL、PostgreSQL、Oracle、SQLite、SQL Server 好几类连接切来切去不用重开窗口。这就决定了它的典型使用场景你手上不止一个数据库或者你主要工作是写 SQL、查数据、导表格而不是天天做备份策略和性能调优再或者你需要经常把结果集导出成 Excel、CSV 交给业务方。这些活 Navicat 干得又快又舒服。反过来如果你要做的是索引碎片整理、执行计划深度分析、Always On 高可用配置那还是老老实实回 SSMS那边才是主战场。需要先说清楚的是Navicat 在连接 SQL Server 的时候底层并不是自己造了一个协议栈绝大多数情况是通过微软提供的驱动早期是 SQL Server Native Client后来是 ODBC Driver 17/18跟数据库对话。这一点非常关键因为后面你遇到的连接报错十有八九不是 Navicat 本身的锅而是驱动层面的默认参数在作妖。理解了这个前提排查问题时你才知道该往哪个方向看。1.2 版本与授权别把时间浪费在歪路上网上关于这款软件的搜索结果里混杂着大量来路不明的安装包和所谓密钥、注册码、破解补丁这里我明确建议不要碰原因有三点都是实打实的经验。第一是安全。第三方打包的安装程序里塞后门、挖矿程序、凭据窃取模块的案例太多了尤其是数据库客户端这类工具它手里握着你所有生产库的连接串和密码一旦被动手脚损失不是几台机器的事是整条数据链。第二是稳定性被改过校验逻辑的程序在高版本系统上容易出现各种诡异崩溃你写 SQL 写到一半闪退那滋味很难受。第三是合规公司内网环境里跑非授权软件被审计出来是要担责的。那正经的路子有哪些官方对这款软件提供 14 天全功能试用足够你把一个项目跑通另外官方推出了免费的 Lite 版本Navicat Premium Lite功能做了裁剪日常的建连、查询、表设计、数据查看都能用只是数据传输、数据同步、自动化任务这些批量功能不开放个人学习和小型项目完全够。预算允许的话直接买正版订阅或者永久授权按月或按年摊下来比你在各种资源站反复折腾安装包省心得多。我自己的习惯是学习机装免费版工作机装正版两边操作逻辑一致不会因为环境差异产生误判。1.3 和其它客户端横向对比选工具这件事不该拍脑袋我把几个常见选项按实际使用感受列个表你可以对着自己的场景挑。工具优势短板适合谁Navicat Premium跨库统一体验数据传输/同步强导出顺手商业授权批量功能需付费版多库并存、以查询和导出为主的开发者SSMS官方全功能执行计划、Profiler、Agent 齐全启动慢只服务 SQL ServerDBA、性能调优、运维Azure Data Studio轻量、跨平台、笔记本式查询少了些管理功能中文资料偏少Mac/Linux 上用 SQL Server 的人DBeaver开源免费驱动生态广大数据量下界面响应偏慢预算敏感、愿意折腾配置的人从表里能看出来Navicat 的位置其实很清晰它不是要替代 SSMS而是补上日常高频轻操作这块短板。我在实际项目里的分工就是这样写查询、拉数据、给业务导表用 Navicat改索引、看执行计划、配作业用 SSMS各干各的活效率最高。你不用非得二选一。2. 连接之前SQL Server 这边要先做好的四件事2.1 装哪个版本、装成什么形态的实例很多人连接失败根子其实不在 Navicat而是在装 SQL Server 的时候就没配对。先把版本理一理SQL Server 目前常见的有 2016、2017、2019、2022 几个大版本。生产环境建议 2019 或 2022安全补丁和维护周期都还在老系统里跑 2008 R2 的也不少能用但要知道它已经停止支持只适合封闭内网。个人学习和测试直接装 2022 的 Express 版本或者 Developer 版本——Developer 版功能和企业版一致只是授权上限定不能用于生产拿来练手是最优解。安装包从微软官方渠道下别去网盘找某某整合版。安装时有个必选项要留心实例类型。默认实例只有一个服务名是MSSQLSERVER装完之后用localhost或者.就能连端口默认 1433。命名实例可以在一台机器上装好几个比如SQLEXPRESS、DEV01服务名是SQL Server (SQLEXPRESS)这种格式连接时必须写机器名\实例名比如DESKTOP-ABC\SQLEXPRESS或者固定端口后用127.0.0.1,端口号连。Express 版默认装出来就是命名实例SQLEXPRESS这是新手最容易踩的坑明明服务在跑Navicat 里填localhost死活连不上就是因为实例名没写。装完第一件事打开 SQL Server 配置管理器在SQL Server 服务节点里看一眼真实的实例名这个信息记下来后面新建连接直接用。2.2 启用 TCP/IP 并锁定端口SQL Server 默认安装完TCP/IP 协议在很多版本里是已禁用状态尤其是 Express 版本。它默认只开着共享内存协议本机的 SSMS 能连但走网络的客户端包括 Navicat 用 TCP 方式就连不上。操作路径是开始菜单搜SQL Server 配置管理器展开SQL Server 网络配置找到你的实例对应的XX 实例的协议右侧会看到 Shared Memory、Named Pipes、TCP/IP 三个。Shared Memory 默认启用TCP/IP 默认禁用。选中 TCP/IP右键属性切到IP 地址选项卡。这里会列出 IP1、IP2……直到 IPAll。前面那些是给具体网卡绑端口的一般不用管重点看最下面的 IPAll 区域。如果你希望用固定端口就把TCP 动态端口清空在TCP 端口里填 1433如果让它自动分配就把两个都留空让它动态走然后通过 SQL Server Browser 服务UDP 1434来告诉客户端实际端口。我的建议是本地开发环境直接固定 1433省去一堆麻烦生产环境如果一台机器上有多个实例才考虑用动态端口 Browser 服务的方案。改完之后一定要重启服务才生效注意是重启SQL Server (实例名)这个服务不是重启 Navicat。重启完用一条命令验证一下端口是不是真的在监听netstat -ano | findstr :1433看到类似TCP 0.0.0.0:1433 0.0.0.0:0 LISTENING这样的输出说明端口起来了。如果只看到127.0.0.1:1433而没有0.0.0.0说明只监听了本机回环地址远程还是连不上这时候要回去检查 IP 地址选项卡里有没有把对应网卡的活动和已启用勾上。2.3 改成混合验证模式并启用一个专用账号SQL Server 有两种身份验证方式仅 Windows 身份验证、SQL Server 和 Windows 身份验证混合模式。默认安装时很多向导页选的是仅 Windows 身份验证这种模式下你用用户名密码是永远登不进去的会一直报 18456。改法有两种。第一种是用 SSMS 以 Windows 身份登录进去右键服务器根节点 → 属性 → 安全性把服务器身份验证改成SQL Server 和 Windows 身份验证模式确定后重启 SQL Server 服务。第二种是直接写注册表但我不推荐改配置这种事绕开官方界面容易留下隐患。改完之后还要启用登录名。默认的sa账号是禁用的右键安全性 → 登录名 → sa先在常规页设一个足够复杂的密码再切到状态页把登录改成已启用确定。如果你的环境对密码策略有要求可以勾选强制实施密码策略让它校验复杂度本地练习图方便的话也可以取消勾选但别在生产环境这么干。顺便说个我的习惯生产环境从来不直接用 sa 连业务库。给每个项目建一个独立的登录名只授权它需要的那几个库和表权限用最小化原则。这样万一某个应用的连接串泄露了影响面是可控的。sa 只在初始化阶段用一次用完就禁用。验证配置是否生效可以直接在查询窗口跑一段 T-SQLSELECT VERSION AS 版本, SERVERPROPERTY(InstanceName) AS 实例名, SERVERPROPERTY(IsIntegratedSecurityOnly) AS 仅Windows验证;IsIntegratedSecurityOnly返回 1 表示当前还是仅 Windows 验证模式返回 0 才是混合模式可以正常用账号密码登录。2.4 防火墙放行与连通性自检前面三步都对了还是连不上八成就是防火墙。Windows 防火墙默认会拦掉入站的 1433 端口本机测试可能不受影响但一换到局域网另一台机器就失败。用管理员权限打开 PowerShell一条命令搞定New-NetFirewallRule -DisplayName SQL Server 1433 -Direction Inbound -Protocol TCP -LocalPort 1433 -Action Allow习惯用 cmd 的话等价写法是netsh advfirewall firewall add rule nameSQLServer1433 dirin actionallow protocolTCP localport1433注意一点如果你的实例用的是动态端口除了主端口还要给 SQL Server Browser 服务放行 UDP 1434否则客户端解析不出实际端口。另外很多安全软件比如某些终端防护套件会额外拦一道加完系统防火墙规则还连不上就把防护软件临时关掉试一次能连就是它在拦。连通性自检我一般分两步先在 Navicat 所在机器上用telnet 目标IP 1433或者 PowerShell 的Test-NetConnection 目标IP -Port 1433试端口通不通这一步通了再看账号密码问题不通就回服务器查监听和防火墙。把网络层和认证层分开排查能省下大量瞎试的时间。3. Navicat 侧新建连接每个字段都掰开揉碎3.1 连接窗口的字段与填写规则打开 Navicat点连接 → 选SQL Server弹出的窗口里字段不算多但每一个都有讲究。字段填写规则常见错误连接名自定义建议带环境标识写成test后面自己都分不清主机IP 或 机器名命名实例写在斜杠后命名实例只填 localhost端口固定端口填 1433动态端口留空填了端口却和实际不一致身份验证SQL Server 身份验证 / Windows 身份验证模式选反用户名sa 或专用账号用了没启用的账号密码对应账号密码密码里有特殊符号被截断初始数据库可留空登录后手动切填了不存在的库名导致连接失败命名实例的写法是最容易出问题的地方。正确格式是主机名\实例名比如192.168.1.50\SQLEXPRESS。如果你希望走 IP 加端口的方式就写成主机填192.168.1.50、端口填实际端口不要在下拉框里选实例名那一栏。两种方式选一种别混着写混着写必然报错。连接名我建议养成命名习惯公司-测试-SQL2019、本地-SQLEXPRESS这种一眼能看出环境和用途。等你有二十个连接的时候就知道这个习惯有多值钱了。3.2 连接测试与报错一一对应填完点测试连接成功就完事失败的话报错信息其实很有信息量关键看括号里那串错误码。[08001] [Microsoft][ODBC Driver 18 for SQL Server]命名管道提供程序: 无法打开这个报错翻译成人话是客户端按命名管道方式去连没找到目标。原因通常是实例名写错、TCP/IP 没启用、服务没启动这三者之一。先确认服务在跑再确认协议开了最后确认实例名按这个顺序排。错误 40 - 无法打开到 SQL Server 的连接和错误 26 - 定位指定的服务器/实例时出错是亲兄弟前者偏网络层后者偏实例解析层。错误 26 如果是命名实例几乎可以断定是 SQL Server Browser 服务没启动去服务列表里把SQL Server Browser设成自动启动。用户 sa 登录失败。原因: 未与信任 SQL Server 连接进行关联。(Microsoft SQL Server, 错误: 18456)这种直接回第 2.3 节检查验证模式和账号状态两者必有一个没弄对。还有一个近两年非常高发的报错SSL Provider: 证书链是由不受信任的颁发机构颁发的。这是 ODBC Driver 18 的默认行为变了——它默认强制加密连接而开发机上的 SQL Server 用的自签名证书自然不被信任。解法是在 Navicat 连接属性的高级选项卡里把加密选项调成可选或者勾选信任服务器证书再或者在 ODBC 附加参数里追加TrustServerCertificateYes;EncryptOptional。这个坑不解决很多人会在密码明明是对的这件事上怀疑人生很久。3.3 高级选项卡加密、超时、SSH 隧道高级这个选项卡平时不用动但有几个开关值得知道。保持连接间隔默认可能不开如果你连的是云上的数据库中间隔了负载均衡空闲几分钟连接就会被掐断表现为过一会儿点表就报连接已断开。把保持连接间隔设成 60 秒左右客户端会定期发心跳基本能解决。连接超时局域网设 10 秒够了跨公网建议 30 秒往上别设太小否则网络稍微抖一下测试连接就失败误导判断。限制连接数单机自用不用管如果多人共用同一套连接配置或者程序化调用把它设成 2 到 5避免一次打开几十个会话把数据库的连接数吃满。SSH 隧道和 SSL 这两个是给远程场景用的。SSH 选项卡的原理是先连跳板机的 SSH再从跳板机转发到数据库端口适合数据库只对内网开放、你需要在外面维护的情况但要注意跳板机的账号权限要收好别用 root 直连。SSL 选项卡就是前面说的加密相关走公网的话建议开启配套装好服务端证书纯内网自用关掉更省事。4. 常用功能实操从建库建表到数据搬运4.1 查询编辑器写 T-SQL 的手感调优连接建好之后最常用的就是左上角的查询 → 新建查询。这个编辑器的几个设置值得花五分钟调一下之后每天都能省时间。首先是自动完成。在工具 → 选项 → 编辑器里把代码自动完成打开补全延迟调到 100 毫秒左右。SQL Server 的对象名前缀比较长dbo.、sys.有补全能少敲很多。其次是执行方式。Navicat 的执行按钮有两个语义一个是执行全部语句快捷键 CtrlR一个是执行当前选中的语句CtrlShiftR。我强烈建议养成选中再执行的习惯尤其是脚本里有DELETE、UPDATE的时候。这个习惯救过我很多次因为有时候鼠标点错位置光标停在哪就执行哪全脚本跑一遍是灾难。第三是结果集的处理。查询出来的结果默认在一个网格里显示几千行还行上百万行就会卡。这种情况我会改用导出功能直接落成文件而不是在网格里滚动。另外工具 → 选项 → 记录里可以设置单次查询最大返回行数默认可能是 1000很多人以为是数据少了其实是这个限制在起作用需要看全量数据时把它调大或者清空。顺手把 SQL Server 里最常用的时间函数过一遍写报表的时候天天用SELECT GETDATE() AS 当前时间, SYSDATETIME() AS 高精度当前时间, DATEADD(DAY, -7, GETDATE()) AS 七天前, DATEDIFF(DAY, 2024-01-01, GETDATE()) AS 相差天数, CONVERT(VARCHAR(19), GETDATE(), 120) AS 标准格式, FORMAT(GETDATE(), yyyy-MM-dd HH:mm:ss) AS 自定义格式, DATEPART(HOUR, GETDATE()) AS 当前小时, EOMONTH(GETDATE()) AS 本月最后一天;CONVERT的第三个参数是样式码120 是yyyy-mm-dd hh:mi:ss112 是yyyymmdd这两个用得最多。FORMAT更直观但性能比CONVERT差不少大数据量报表里别在WHERE条件中用FORMAT会让索引失效。4.2 三兄弟数据传输、数据同步、结构同步这三个功能是 Navicat 区别于轻量客户端的核心价值但很多人分不清它们各自干什么我先说清楚。数据传输把源连接里的表和数据整体复制到目标连接。典型场景是测试库刷成生产库的副本、把本地开发数据推到测试环境。用法是右键源库 → 数据传输选目标连接和目标库勾选要传的表。选项里有几个关键开关遇到错误是否继续建议先关掉先看错误、是否使用事务数据量大时开着更安全但速度慢、是否包括外键约束和触发器。数据同步源和目标两边表结构一样只想把差异数据补齐或更新。它的工作方式是生成一系列INSERT、UPDATE、DELETE语句。这里有个重要细节很多版本里数据同步是单向的它会把目标端多出来的行删掉、少掉的行插进去让目标端完全等于源端。用之前一定要看清楚界面上标的箭头方向反了就是把生产数据往测试库里推或者更糟。结构同步只对比表结构差异生成ALTER TABLE语句不碰数据。做版本发布的时候特别有用可以先把测试库的结构改动同步到生产库再单独处理数据变更。我的使用原则是任何一次同步或传输操作前先对目标库做一次备份哪怕只是导出成 SQL 文件。这三个功能威力大但都是改数据的操作没有撤销键。4.3 备份还原与计划任务Navicat 里的备份功能本质上是帮你执行BACKUP DATABASE语句生成的.bak文件。这里有个关键点必须讲清楚备份文件的路径是 SQL Server 服务所在那台机器上的路径不是 Navicat 所在机器的路径。因为这个路径是传给数据库引擎去写的。所以如果你在 Navicat 里填了一个本地 D 盘路径而数据库在另一台服务器上备份会失败或者文件跑到服务器上去了你在本地找不到还以为丢数据了。还原同理选.bak文件的时候列表出来的是服务器端能看到的文件不是你的本地磁盘。如果.bak是从别处拷过来的得先把它放到服务器上能被 SQL Server 服务账号读到的目录里。还有一个常见的还原报错是无法覆盖正在使用的文件因为.mdf/.ldf的原始路径在服务器上已经存在同名文件这时候要在还原的选项里勾选移动文件把物理路径改到新的目录。计划任务这块Navicat 自带一个自动运行功能可以定时执行备份、查询、导出。但要注意它的运行机制任务需要 Navicat 客户端在那台机器上保持可用状态本质上是客户端在调度不是数据库在调度。所以它适合个人定时导出报表这种轻量需求真正的生产级定时备份和 ETL还是交给 SQL Server Agent 作业更稳妥毕竟那是引擎自带的能力不依赖任何客户端在线。4.4 表设计器、外键、索引和权限表设计器是可视化改结构的入口右键表 → 设计表。改字段类型、加默认值、设主键都很直观改完点保存会生成对应的ALTER语句。这里有个经验设计器在改字段类型的时候可能触发数据转换如果字段里已有数据且转换会丢精度比如varchar转int它会失败并报错改之前先确认数据内容。所以视情况还是建议直接用 T-SQL 改可控性更高。外键在外键选项卡里配选本表字段、目标表、目标字段、更新和删除时的行为级联/置空/限制。生产库里我对级联删除一直很谨慎因为它太隐蔽了删一行主表数据下面几万行子表数据静悄悄没了事后排查都很困难。习惯做法是用ON DELETE NO ACTION删除逻辑在应用层显式处理。索引在索引选项卡建。Navicat 里能建普通索引、唯一索引、聚集索引。一个实用技巧可以通过工具 → 查询创建工具看出某个查询的过滤字段据此判断该给哪一列加索引。不过索引该不该加、加几个还是得看实际执行计划这个后面单独说。用户和权限这块Navicat 对 SQL Server 的支持不如它对 MySQL 那么完整。它能看到登录名、用户、角色也能建一些基础账号但涉及到 schema 级权限、数据库角色成员的精细配置还是回 SSMS 写 T-SQL 更靠谱-- 建一个只读账号 CREATE LOGIN app_readonly WITH PASSWORD 一个足够复杂的密码; USE SalesDB; CREATE USER app_readonly FOR LOGIN app_readonly; ALTER ROLE db_datareader ADD MEMBER app_readonly;这套语句比在图形界面里点来点去要清楚得多也方便纳入版本管理。5. 高频问题速查与避坑记录5.1 连接类问题速查表现象最可能的原因处理路径命名管道提供程序无法打开TCP/IP 未启用或实例名错配置管理器开协议核对实例名错误 26 定位实例失败SQL Server Browser 未启动服务改为自动并启动错误 40 无法打开连接防火墙或服务异常检查服务状态、放行端口18456 登录失败验证模式或账号状态改混合模式启用账号证书链不受信任驱动默认强制加密信任服务器证书或改加密为可选忘记密码需要重置用 Windows 管理员身份登入后重设这张表我建议截图存在本地下次报错直接对号入座比你从头分析快得多。这里面的每一条我在不同项目里都遇到过尤其是证书链不受信任这条最近两年因为驱动版本更新导致出现频率极高。5.2 功能类问题速查表现象原因处理删库报数据库正在使用有活动连接占用切单用户模式后删除中文显示成问号字段用了 varchar 存中文改用 nvarchar字符串前加 N查询只返回 1000 行客户端返回行数限制工具选项里调大或清空导出 Excel 卡死数据量过大分批导出或改 CSV备份文件找不到路径是服务器端路径去服务器上找或用共享目录还原报文件被占用同名物理文件存在勾选移动并指定新路径删库那个问题值得多说一句这是搜索里经常出现的一类需求。SQL Server 删数据库失败通常不是权限问题而是有连接正在占用。处理方式是先把数据库踢成单用户模式把其他连接都断开再删ALTER DATABASE SalesDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE; DROP DATABASE SalesDB;WITH ROLLBACK IMMEDIATE的意思是立即回滚未完成的事务并断开其他连接执行前确认没有人正在跑重要业务否则等于强行掐断。中文乱码的根子在于 SQL Server 里varchar是非 Unicode 类型存中文依赖排序规则和代码页跨版本跨系统容易出问题。建表时凡是可能存中文、人名、地址、备注这类内容一律用nvarchar写常量的时候前面加N比如N张三。这个N很多人漏掉漏了之后数据进去就变成问号而且不一定立刻发现。5.3 几个我踩过的坑第一个坑是连接配置跟着项目走却没有版本管理。团队里有个人改了连接参数其他人跟着出问题。后来我们的做法是Navicat 的连接配置只在本地维护团队共享的配置全部走配置文件或环境变量谁都不许直接改公共连接。第二个坑是误用数据同步方向。有一次测试环境要刷数据界面上的方向选反了差点把测试库的脏数据推到生产。后来定了条死规矩任何同步操作之前先看一眼源和目标连接的名称再确认一遍界面上的箭头方向最后对目标做一次结构备份。三步做完再点执行。第三个坑是长事务导致的锁等待。在 Navicat 里开了个事务跑了UPDATE之后忘了提交也没关窗口结果其他会话全被堵住业务那边开始报超时。现在我的习惯是在 Navicat 里做修改类操作先用BEGIN TRAN显式开事务验证行数对了再COMMIT不确认就ROLLBACK。而且做完立刻关掉那个查询窗口不给遗忘留机会。第四个坑是导出时的编码。导出 CSV 给业务方用 Excel 打开中文乱码原因是 Excel 默认按本地编码解析。解决办法是导出时选带 BOM 的 UTF-8 编码或者在选项里直接选 GBK看接收方的环境定。这个坑很不起眼但每次交付数据都会遇到。第五个坑是自动重连。网络波动导致连接断了Navicat 默认会尝试重连重连之后你的查询窗口上下文可能已经变了比如当前数据库被重置回默认库。所以执行跨库脚本的时候我习惯在脚本开头显式写USE 目标库;不依赖界面左上角那个数据库下拉框的状态。这套连接和常用功能的东西讲到这里基本能覆盖日常大部分的活。查询性能优化相关的部分其实是另一条线比如怎么读执行计划、Profiler 怎么抓慢查询、索引该怎么配那块单独拿出来讲才说得透我后面会另开一篇专门聊。
返回列表