上周三早上九点我照例打开 Navicat Premium 准备扒一下生产库的慢查询结果左侧连接列表一片空白昨天还在的七八个连接全没了。那一瞬间的心情做过运维的人应该都懂——不是怕连不上而是怕那几十个连接的密码、跳板参数、SSH 隧道配置全都要重新问一遍。后来花了大概四十分钟把所有连接一条不落全捞了回来连密码都没重输。这篇就把整套姿势完整说一遍Navicat 的数据库连接配置到底存在哪、什么情况下会丢、丢了之后按什么顺序去找、哪些操作会把找回的路堵死。不管你是刚装完 Navicat 连接 MySQL 的新手还是手上同时管着 MySQL、Oracle、PostgreSQL、达梦好几套库的老运维这套流程都能直接抄。全文只讲正规的配置找回与备份思路不涉及任何非正规授权相关的操作。1. 想找回先得知道它藏在哪1.1 一个连接在 Navicat 里其实是三样东西很多人以为连接就是个IP 端口 账号密码其实在 Navicat 内部一条连接是拆成三块存的这三块丢的东西不一样找回的难度也完全不同。第一块是连接条目本身也就是你左侧列表里看到的那个名字、图标、分组。它包含主机地址、端口、数据库名、用户名这些非敏感参数。第二块是加密后的密码它和第一块存在同一个配置文件里但字段是加密过的不是明文。第三块是连接的高级属性包括 SSH 隧道设置、SSL 证书路径、字符集、连接超时、Keep-Alive 间隔等等。这三块里第一块和第三块最容易恢复因为它们本质上就是一堆文本参数第二块比较麻烦因为 Navicat 对密码做了加密加密密钥和当前机器的环境信息绑定所以换个机器直接把文件拷过去经常会出现连接能显示、密码栏空着的情况。理解了这一点后面所有找回动作的原因就都说得通了——我们找回的核心目标其实是连接条目 高级属性密码是次要的大不了重输一遍。1.2 各操作系统下的配置文件路径对照Navicat 12 之后的版本配置不再写注册表了改成文件存储。这是好消息因为文件比注册表好备份、好恢复、好版本管理。下面是各平台的实际路径建议你直接复制到自己机器上核对一遍。操作系统配置根目录Navicat 12 及以上关键文件WindowsC:\Users\用户名\AppData\Roaming\PremiumSoft\Navicat Premium\Navicat Premium.ncx、Navicat Premium.ncx.bakWindows日志/备份/查询记录C:\Users\用户名\Documents\Navicat\Premium\各数据库类型的备份目录、查询保存记录macOS~/Library/Application Support/PremiumSoft CyberTech/Navicat Premium/Navicat Premium.ncx、同名备份文件Linux~/.navicat64/或~/.config/navicat/Navicat Premium.ncx或对应版本命名的 ncxWindows 上有个细节需要注意AppData\Roaming是隐藏目录直接在文件资源管理器地址栏敲%APPDATA%\PremiumSoft回车最快比一层层点进去省事。macOS 上则是~/Library默认隐藏访达里按Command Shift G粘贴路径就能跳过去。注意如果你的 Navicat 是 11 及更早的版本配置不在上面这些路径里而是写在注册表HKEY_CURRENT_USER\Software\PremiumSoft\Navicat\Servers下面。找回思路不一样第 3 节会单独讲。1.3 ncx 文件到底是什么能不能直接看懂Navicat Premium.ncx这个文件本质上是一个结构化的配置文件里面承载了你所有连接的列表和加密后的凭据。它有几个兄弟文件经常被忽略但在找回时价值极高Navicat Premium.ncx.bakNavicat 自己生成的备份文件通常是你上一次保存配置前的状态。Navicat Premium.ncx~某些版本在写入过程中产生的临时文件异常退出时会留下。你手动导出的.ncx通过导出连接功能生成的独立文件这是最理想的恢复源因为它可以包含密码、可以按需选择连接。我实测过把一个几百 KB 的 ncx 直接用文本编辑器打开能看到连接名称、主机、端口这些字段是明文可读的但密码字段是一串密文。这意味着一件事只要 ncx 文件还在你的连接列表就还有救但光有 ncx 文件密码大概率救不回来。所以后面的找回策略会分两条线走——条目靠文件密码靠备份或重输。2. 先分清楚是哪种丢失别上来就瞎折腾2.1 场景一误删、误操作、软件异常退出这是最常见的一种。典型表现是昨天还好好的今天打开列表空了或者你点了某个清理功能结果连配置一起清了。还有一种是软件崩溃后重启配置文件写坏了一半。这种场景的特点是有时间点——你知道大概是哪个操作之后丢的。所以第一反应应该是立刻停止在 Navicat 里做任何写入操作包括新建连接、改设置、点保存。因为一旦 Navicat 重新生成了一份新的、内容为空的 ncx覆盖掉旧的找回难度会直接从简单跳到困难。我见过不少人丢了配置之后慌里慌张到处点结果把.ncx.bak也覆盖了最后只能一个个重配。2.2 场景二升级、重装、换版本导致路径漂移Navicat Premium 从 15 升到 16、17或者从 Premium 换成 Premium Lite配置目录名可能会变。比如 Premium 的目录叫Navicat Premium而 Lite 版可能是另一个名字。另外如果你当初装的是免安装版、绿色版配置可能跟着程序目录走一旦你把程序文件夹挪了位置Navicat 就找不到配置了表现就是连接全没了。这种场景其实是最好解决的因为旧配置一直在那只是新程序没读它。你需要做的不是找回而是指路——把旧目录里的 ncx 复制到新目录或者直接用导入功能。2.3 场景三系统重装、磁盘故障、用户目录被清空这是最伤的一种。重装系统时如果只格式化了 C 盘而你的配置在C:\Users\用户名\AppData下那就一起没了。磁盘坏道导致用户目录部分文件损坏也会出现类似情况。这种情况能不能救完全取决于你之前有没有做过备份。如果没有任何备份那就只能退回到重建连接的路子上这时候你能依靠的就是浏览器里存过的数据库管理后台地址、项目的配置文件比如 Spring Boot 的application.yml、WordPress 的wp-config.php、Django 的settings.py里写着的数据库参数。这些地方经常能凑齐主机、端口、库名、用户名唯一缺的就是密码。2.4 场景四换电脑、多设备协同从公司台式机换到笔记本或者家里、公司两头办公这是很典型的场景。很多人第一反应是把 ncx 拷过去结果发现连接是出来了但密码栏空着点连接报 1045。这不是你的操作错了而是前面说的加密机制导致的。跨机器导入 ncx密码需要重新输入这是设计如此不是 bug。所以正确的做法是换机器之前用导出连接功能导出一份带密码的 ncx但即便如此也要做好在新机器上重新输密码的心理准备具体能不能解出来跟版本和导出方式都有关系我实测下来新版经常是需要重输的。3. 实操六种找回方法按优先级往下走3.1 第一优先级回收站和系统文件历史如果你是在 Windows 上误删了 ncx 文件第一步永远是打开回收站看一眼。Navicat 自己不会把 ncx 往回收站扔但如果是你手动清理目录、或者用了某些清理软件那 ncx 可能就静静躺在回收站里。找到之后右键还原回到原路径重启 Navicat 就行。如果回收站里没有Windows 10/11 的文件历史记录或者 OneDrive 的文件版本历史是第二道防线。前提是你开过这个功能——AppData目录默认不在文件历史记录的监控范围内但如果你手动加过那就赚了。macOS 用户对应的是时间机器Time Machine只要备份盘里有过快照进~/Library/Application Support/PremiumSoft CyberTech/用时间机器回溯到丢失前的日期把整个目录恢复出来就行。提示这一步的关键是快。文件被覆盖之后恢复工具的成功率会断崖式下降。所以发现丢失的第一分钟先别动 Navicat。3.2 第二优先级扒.ncx.bak和同名残留文件回到第 1.3 节提到的那些兄弟文件。在配置目录里除了主文件Navicat Premium.ncx你大概率还能看到一个Navicat Premium.ncx.bak。把它复制一份出来改名为Navicat Premium.ncx记得先把现有的坏文件重命名备份然后重启 Navicat。我自己的经历是那次连接全空就是因为主 ncx 在异常退出时写坏了而.bak是完好的改名替换之后七八个连接全回来了包括 SSH 隧道配置。这一步的代价几乎为零但收益极高所以排在很靠前的位置。还有几个容易被忽略的文件值得翻一翻如果你用的是 Portable 版本配置可能就在程序目录下的Data文件夹里如果你装过多个 Navicat 版本AppData\Roaming\PremiumSoft\下面可能会有好几个平行的目录挨个看一眼说不定旧版本的配置还完整地躺在那。3.3 第三优先级导入之前导出的.ncx备份如果你之前用 Navicat 的导出连接功能做过备份那这一步就是最简单的。操作路径是在 Navicat 主界面右键点击连接区域的空白处选择导入连接然后选你之前导出的 ncx 文件。可以选择全部导入也可以只挑其中几个。这里有个实操细节值得说导出的时候一定要勾选包含密码。如果没勾导入进来的连接是需要重新输密码的。另外如果导出时勾了包含密码导入到的又是同一台机器那密码通常能正常解出来换成另一台机器就不一定了——这跟前面讲的加密机制有关也是为什么我建议把导出的 ncx 文件当成条目备份而不是密码备份来看待。导出的频率上我的习惯是每次批量新增或修改连接之后立刻导出一份文件名带上日期比如navicat-conn-20240612.ncx全部丢进一个同步盘目录。这样即使某天配置全丢最多也就损失当天的几条改动。3.4 第四优先级从旧用户目录整体搬迁如果是升级、换版本导致的找不到配置思路就很直接了先在新版本的配置目录里确认它生成的空 ncx 叫什么名字然后退出 Navicat把旧目录的 ncx 复制过去覆盖再启动。实际操作中有个坑要避开不要在两个 Navicat 同时运行的情况下直接覆盖配置文件很容易出现后启动的那个把文件重新写一遍导致覆盖白做。正确顺序永远是退出所有 Navicat 进程 → 复制文件 → 启动。Windows 上可以在任务管理器里搜一下navicat确认没有残留进程macOS 上用活动监视器或终端ps aux | grep -i navicat看一眼。如果是绿色版/免安装版还有一个变量是程序目录被移动过。这时候 Navicat 会在启动时新建一个空配置旧配置还留在原来的位置。找到它按上面的方式搬过去即可。3.5 第五优先级老版本的注册表导出与还原Navicat 11 及更早的版本连接信息在注册表里。找回思路是先想办法拿到一份注册表备份如果你之前用导出连接功能导出过.ncx那在旧版本上导入即可这是最省事的。如果是系统重装前做过注册表备份.reg文件双击导入然后重启 Navicat。如果什么都没有但旧硬盘还在拆下来接成移动硬盘可以用离线方式加载旧系统的注册表配置单元把HKEY_CURRENT_USER\Software\PremiumSoft\Navicat\Servers这一支导出来。注意注册表操作属于高风险动作动手前务必先导出一份当前的注册表作为保险。修改注册表导致系统异常的例子我见过不止一次。3.6 兜底方案重建连接从项目里把参数扒回来前面五步都没救回来那就只能重建。但重建不等于抓瞎参数其实散落在很多地方参数常见来源主机、端口项目配置文件application.yml、.env、wp-config.php、Docker Compose 文件、云数据库控制台数据库名同上或者直接连上去SHOW DATABASES;看一眼用户名项目配置、运维文档、堡垒机里保存的记录密码密码管理器、团队共享的凭据库、CI/CD 的环境变量配置重建的时候有个提效技巧先用一条能连上的基础连接主机 端口 用户名 密码连上去之后再用 SQL 去查有哪些库这样你就不用挨个回忆库名了。MySQL 里SHOW DATABASES;PostgreSQL 里\lOracle 里SELECT name FROM v$database;都能快速列出来。顺便说一句如果你手上有多个数据库要管——MySQL、Oracle、PostgreSQL甚至达梦这种国产库——重建连接的时候正好可以顺手把命名规范统一一下比如用环境-类型-用途的格式像prod-mysql-order、test-pg-report以后找起来快很多。至于 Elasticsearch 这类偏搜索场景的Navicat 并不是最趁手的工具它更适合用 Kibana、Cerebro 或者对应的命令行工具来管理不用强行塞进 Navicat 里。4. 密码这块的边界和正确姿势4.1 为什么换个机器密码就解不开前面反复提到这个现象这里把它讲透。Navicat 12 之后对密码的处理大致是这样的逻辑密码不是明文存储而是加密后存在 ncx 里加密用的密钥跟当前用户环境比如用户目录下的某些标识信息、机器相关因素有关联。所以同一台机器、同一个用户ncx 拿回来密码通常能自动解出来直接能用。同一台机器、换了 Windows 用户可能就解不出来了。换了一台机器大概率需要重新输入密码即便导出时勾了包含密码。理解这一点之后你就能明白为什么把 ncx 拷到新电脑就能用这种说法不靠谱。它能不能用取决于版本和具体环境属于有时行有时不行不能作为依赖。4.2 密码应该怎么管才不依赖 Navicat我的做法是把连接参数和密码彻底解耦参数主机/端口/库名/用户名进文档用 Markdown 表格维护在一个私有的知识库里或者直接用 Navicat 的备注字段写在连接上导出 ncx 时备注会一起带走。密码进密码管理器比如团队统一用一个凭据管理工具或者至少用本地的密码管理器按环境-库名-账号建条目。这样即使 Navicat 配置全丢密码也能一条条捞回来。绝不把生产库密码写在项目代码里application.yml里的密码字段应该走环境变量或者配置中心这个既是安全要求也顺便避免了配置丢了一起丢的连带风险。提示网上流传的一些所谓从 ncx 里解密密码的脚本或者小工具我不建议用。一方面新版密钥跟机器绑定通用性很差跑不通是常态另一方面来路不明的可执行文件本身就是风险源。2024 年就有过伪装成数据库工具安装包、实际植入恶意程序的案例装之前想清楚值不值。4.3 连不上不等于丢了先把报错读明白很多时候你以为的连接丢了其实是连接还在、只是连不上。这两种情况处理方式完全不同所以先看报错。报错码/提示常见原因处理方向1045 Access denied用户名或密码错、权限不足核对密码检查账号的 host 白名单2003 Cant connect to MySQL server (10061)服务没启动、端口不通、防火墙拦截先telnet 主机 端口测连通性1049 Unknown database库名写错或库不存在连上去SHOW DATABASES;核对10060 连接超时网络不通、云安全组未放行检查安全组、路由、是否走了正确的网络ORA-12541 TNS:no listenerOracle 监听没起或端口不对检查监听状态和端口SSH 隧道相关报错跳板机配置变更、密钥失效单独测试 SSH 连通性我把上面这张表贴在团队共享文档里新同事遇到问题先自查能省掉不少沟通成本。顺便说telnet 主机 端口这个动作虽然老土但它是判断网络层通不通最快的方式比在 Navicat 里反复点连接高效得多。5. 让找回这件事从流程里消失5.1 第一层导出 定时把人肉操作变成机器操作Navicat 本身不提供自动导出连接的功能但这件事可以用脚本兜住。核心逻辑就一句话定时把配置目录下的 ncx 文件复制到另一个位置。Windows 上写个批处理配合任务计划程序每天跑一次echo off set SRC%APPDATA%\PremiumSoft\Navicat Premium\Navicat Premium.ncx set DSTD:\Backup\Navicat\%date:~0,4%%date:~5,2%%date:~8,2% if not exist %DST% mkdir %DST% copy /Y %SRC% %DST%\macOS 或 Linux 上一篇 crontab 也能搞定0 2 * * * cp $HOME/Library/Application Support/PremiumSoft CyberTech/Navicat Premium/Navicat Premium.ncx $HOME/backup/navicat/$(date \%Y\%m\%d).ncx这个脚本的价值在于它把记得备份这件事从人的责任心转移到了系统上。我踩过的坑就是——前三年每次都是手动导出结果真出事的时候发现最后一次导出是半年前。5.2 第二层目录级同步覆盖到软件自己写坏的情况定时复制有个盲区如果你在备份时间点之前就把配置写坏了那备份下来的也是坏文件。所以再加一层——用同步盘比如公司允许的网盘或者 Git 对配置目录做版本管理。Git 的好处是每次提交都有历史哪天发现连接少了git log一看就知道是哪次变更动的直接 checkout 回来。不过要提醒一点ncx 里含加密后的凭据不要往公开仓库推。哪怕是加密的也不该出现在公开位置。私有仓库、或者干脆只用本地的同步盘都是更稳妥的选择。5.3 第三层让连接本身可重建最高级的备份是不依赖任何文件。具体做法是把每条连接的关键参数记在能长期保存的地方格式统一。我自己的模板长这样名称: prod-mysql-order 类型: MySQL 8.0 主机: 10.x.x.x:3306 库: order_db 账号: app_order 密码: 见密码管理器 / prod-order 备注: 走 SSH 隧道跳板 10.x.x.10密钥见运维台账有了这么一张表就算 Navicat 重装十遍我重建连接也就是十分钟的事。这个习惯看起来笨但它是唯一一个不依赖任何软件、不依赖任何文件的方案。6. 常见问题速查与踩坑记录6.1 高频问题对照表问题原因解决办法打开 Navicat 连接列表全空ncx 损坏或被覆盖用.ncx.bak覆盖主文件或导入备份的 ncx导入 ncx 后连接在但密码是空的跨机器导入密码无法解密从密码管理器取密码重输或从导出源机器上导出带密码版本升级 Navicat 后连接消失新版本配置目录变了把旧目录的 ncx 复制到新目录退出所有进程后操作连接能连但报 1045密码错或无权限核对密码、检查账号 host 授权回收站里找不到 ncx被清理软件绕过回收站删除用文件历史记录/时间机器回溯或从同步盘历史版本恢复在 Navicat 里点删除连接后想恢复连接条目被删但 ncx 里可能还有残留立刻导出当前 ncx用文本编辑器搜连接名看是否还有残留节点6.2 几个只有踩过才知道的细节第一个别在有未保存操作的时候强杀 Navicat 进程。Navicat 的配置是启动时读、退出时写部分操作会立即写强杀有概率导致写一半。我那次丢失事后回想就是系统更新强制重启导致的。第二个多版本共存时要理清楚哪份配置是活的。机器上同时装了 Navicat Premium 15 和 17两个版本的配置目录可能是分开的你在 15 里改的连接17 里看不到这很正常不是丢。第三个导出 ncx 的时候注意文件名。如果连续导出多次都叫connections.ncx很容易覆盖掉上一份。加上日期和用途比如conn-prod-20240612.ncx、conn-test-20240612.ncx看起来麻烦真出事的时候能救命。第四个给连接加备注是个被低估的习惯。备注会跟着 ncx 一起走即使密码解不出来至少你能从备注里知道这条连接是干嘛的、属于哪个项目、该找谁要密码。第五个团队协作场景下别让每个人的连接配置各存各的。我们现在的做法是维护一份连接清单文档新同事入职照着文档自己建老同事配置丢了也照着文档重建Navicat 的 ncx 只当作个人偏好和工作区的东西不作为唯一真相来源。我个人在实际操作中的体会是找回这件事百分之八十靠的是事前有没有留后手百分之二十才是临场的技术手段。那次四十分钟把连接全捞回来靠的不是什么高深技巧就是ncx.bak这个文件没被覆盖加上我半年前导出过一份 ncx。技术手段能救急但真正让人睡得着觉的是那个每天凌晨两点默默跑一次的复制脚本。