Navicat Premium 12.1 多数据库连接、迁移对账与备份避坑指南

简介：Navicat Premium v12.1.17（x64）绿色中文注册版面向数据库开发、运维及同时连接 MySQL、Oracle 等数据库的学习者，提供解压即用的图形化环境，适合本地快速搭建查询调试工作区。压缩包共118个文件，约92.21MB，以dll动态库为主，配合exe主程序、php脚本、msi组件及pdf/txt说明文档，覆盖主程序运行、数据库驱动和激活辅助等环节。已有1414人学习，具备一定使用验证基础。包内保留多数据库连接所需的核心组件与备份文件，方便体验多库统一管理、SQL编辑和数据传输，也可作为排查驱动缺失、依赖问题的参考；配套文档与激活辅助文件便于按需配置。整体适合希望低成本试用Navicat多库管理能力的中初级开发者和运维人员。

1. 一台机器上同时连 MySQL、Oracle、SQL Server，Navicat Premium 12.1 的价值就在这

数据库客户端换来换去，最后常驻在任务栏里的往往还是 Navicat Premium。它把 MySQL、Oracle、SQL Server、PostgreSQL、SQLite 的连接塞进同一个窗口，左边树形库表、右边 SQL 编辑器，改结构、导数据、看执行计划不用在几个程序之间来回切。手上这份 v12.1.17 x64 属于 12.x 这条老版本分支，装完占的空间不大，能在 Win7 到 Win10 的老机器上起来，很多人拿它当“随手连一下生产库、抓张表给业务”的轻量入口，而不是当建模平台用。它适合日常要跨两三种库对数、做迁移前的结构比对、临时导出 Excel 的人；短板也很明确，12.x 对 MySQL 8 的默认认证插件、对较新的 JSON 函数支持不如后期版本，这些会在后面几个坑里具体展开。

2. 解压即用之后的第一步：连接参数到底怎么填

便携形态的好处是配置文件跟着目录走，U 盘拔了插到另一台机器上，连接列表还在。代价是它不像安装版那样把依赖注册进系统，少一个 dll、目录没有写权限，都会表现成“打不开”或者“打开是空白”。这一章先把启动这一层捋清楚，再逐项过连接对话框。

2.1 便携目录里哪几个位置不能动

解压出来的目录通常长这样：主程序navicat.exe、一堆*.dll、libs或者plugins目录、以及第一次运行后才出现的配置目录。真正需要记住的只有两件事：

• 配置和连接信息默认写在用户目录下（类似%APPDATA%\PremiumSoft\Navicat\），部分便携包会改成写在程序目录同级。想做到“插上就能用、连接不丢”，得确认它是哪一种。判断方法：改一个连接名，关掉程序，看程序目录下有没有新生成的配置文件夹。
• plugins/libs里放的是各数据库的客户端库，Oracle 的连接尤其依赖它。这个目录被清理软件当成“无用文件”删掉，症状是能打开程序但所有 Oracle 连接报驱动错误。

我一般做两件事：把整个目录放到一个不含中文和空格的路径下（比如D:\tools\navicat1217\），然后给当前用户对该目录完全控制权限。路径带中文在老版本上引发的问题很零散，比如导出文件名乱码、计划任务找不到脚本，比起事后排查，不如一开始就避开。

提示：来源不明的改写版有被植入后门或被替换dll的风险，生产库凭据一旦落在这种环境里，代价远大于省下的授权成本。授权走官方渠道，预算紧的场景用 DBeaver、HeidiSQL 这类开源客户端能覆盖大部分日常操作，连接管理、SQL 编辑、导出都不缺。

2.2 新建连接时逐项填什么

点“连接”选数据库类型，弹出来的表单看着简单，实际每个字段都有讲究。以 MySQL 为例：

表单右侧一般有个“高级”页签，里面几项值得改：字符集（MySQL 填utf8mb4）、保持连接间隔（默认 240 秒，跨公网或过负载均衡时缩短到 60 秒）、以及 SSL 相关开关。跨公网连接时把 SSL 打开，本地内网段可以关掉省掉握手时间。这些设置是跟着连接保存的，不用每次重填。

Oracle 表单多一个角色下拉，分 Default、SYSDBA、SYSOPER。日常查询保持 Default 就行，选 SYSDBA 走的是另一套认证路径，很多实例压根没配口令文件，选了就连不上。除非明确要做启停库、改归档模式这类操作，不要碰它。

2.3 连接测试失败先看这三处

报错窗口给出的信息往往只有一行，真正的线索在三个地方：

第一是“详细信息”折叠区。点开通常能看到底层驱动的原始错误码，比如2003（连不上服务端）、1045（账号密码错）、2059（认证插件不兼容）。有原始码才能对症。

第二是本机的出站连通性，先在命令行验证再怀疑客户端：

# 验证端口通不通，-v 输出详细过程，-w 3 表示 3 秒超时 nc -v -w 3 10.0.0.11 3306 # Windows 上没有 nc，用 telnet 或 PowerShell 的 Test-NetConnection powershell -Command "Test-NetConnection 10.0.0.11 -Port 3306"

端口通但客户端连不上，问题就在账号授权或驱动；端口不通，就是网络策略或服务端监听地址（bind-address只监听 127.0.0.1 时，本机之外的连接一律被拒）。

第三是账号的授权范围。MySQL 里'app'@'%'和'app'@'localhost'是两个不同账号，从别的机器连过来匹配的是前者。查一下：

-- 确认账号的 host 匹配范围 SELECT user, host, plugin FROM mysql.user WHERE user = 'app'; -- 确认目标库有没有授权 SHOW GRANTS FOR 'app'@'%';

三处都过了还是连不上，才去看是不是 SSL 强制、是不是中间有代理改写了握手、是不是服务端max_connections打满了。

3. 四种库的驱动差异：参数填对了才叫能用

连接对话框只是外壳，真正干活的是背后的驱动。同一个字段在不同数据库里含义不同，这一章按库拆开讲，都是会直接影响能不能连上、连上之后看不看得见东西的细节。

3.1 MySQL 8 的认证插件与 SSL 开关

MySQL 8 把默认认证插件从mysql_native_password改成了caching_sha2_password。12.x 这一代的客户端对这种新插件的支持不完整，典型表现是密码明明是对的，却报2059 Authentication plugin 'caching_sha2_password' cannot be loaded。

三条路，按场景选：

-- 路线一：把该账号降级回旧插件（改动最小，但削弱了该账号的传输安全） ALTER USER 'app'@'%' IDENTIFIED WITH mysql_native_password BY '你的密码'; FLUSH PRIVILEGES; -- 路线二：服务端开 SSL，新插件在加密通道下才能完整走通（推荐） SHOW VARIABLES LIKE 'have_ssl'; -- 期望 YES SHOW VARIABLES LIKE 'require_secure_transport'; -- 路线三：升级客户端到 15 及以上，从根上支持新插件

路线一改完要FLUSH PRIVILEGES才生效，而且别忘了用同一个账号再连一次验证。路线二需要在客户端连接属性里勾上“使用 SSL”，并指定 CA 证书路径；如果是自签证书，还要允许不受信任的证书，否则报的是另一套证书校验错误。路线三是长期解，但 12.x 的界面和数据传输向导是很多人的肌肉记忆，换版本要重新适应，取舍看团队习惯。

顺带一个容易忽略的点：连上之后看不到某个库，八成不是权限问题，而是这个库的表用的字符集不是utf8mb4，客户端按连接的字符集去解析元数据时出错，树形列表就空了。这时候把连接属性里的字符集明确写死成utf8mb4，重连一次。

3.2 Oracle 的 SID 与 Service Name 之争

Oracle 连接框里最常填错的就是“数据库”这一项。RAC 和单实例的 PDB 场景下，这里要填的是 Service Name；老的单实例库才用 SID。两者填错的表现还不一样：填了不存在的 Service Name，报ORA-12505: TNS:listener does not currently know of SID given in connect descriptor；填了不存在的 SID，报的是ORA-12514。

不确定的时候，从服务端查：

-- 查当前实例注册了哪些 service name SELECT name FROM v$services; -- 查实例名（约等于 SID） SELECT instance_name FROM v$instance;

另一个坑是客户端库。Navicat 连 Oracle 依赖oci.dll一类的客户端库，位数必须和主程序一致（x64 程序配 x64 库）。位数不匹配的报错很含糊，有时是“无法加载 OCI 库”，有时直接崩。便携包里如果自带了这个库，就别再指向系统里装的那份；版本混用同样会出问题，尤其是 Oracle 客户端 19c 连 11g 服务端的组合，要确认兼容矩阵。

NLS_LANG 也值得看一眼。客户端字符集和服务端不一致时，中文会变成问号，而且是在写入那一刻就已经错了，事后改字符集救不回来。Windows 上的常见做法是在系统环境变量里设NLS_LANG=SIMPLIFIED CHINESE_CHINA.AL32UTF8，然后重启客户端进程。

3.3 SQL Server 命名实例与端口回落

SQL Server 默认实例监听 1433，命名实例（主机\实例名）走的是动态端口，需要靠 SQL Browser 服务（UDP 1434）来告诉客户端实际端口。防火墙只放了 TCP 1433 而没放 UDP 1434 时，默认实例能连、命名实例连不上，这个现象很有迷惑性。

两种解法：在服务端配置管理器里把命名实例的 TCP 端口固定下来，然后在 Navicat 的主机字段里写成10.0.0.12,14330（逗号后面跟端口）；或者放开 UDP 1434 让浏览器服务去协商。内网环境我倾向前者，行为可预期，排查的时候也少一层。

还有 Windows 身份验证。连接属性里选“Windows 身份验证”时，用的是当前登录系统账号的凭据，客户端和服务端不在同一个域里基本走不通。跨域场景老老实实建 SQL 账号，并且注意服务端可能开着“仅限 Windows 身份验证”模式，这种模式下 SQL 账号压根不能登录，需要在服务端改认证模式并重启实例。

3.4 PostgreSQL 的 search_path 与 schema 可见性

PostgreSQL 连上之后看不到业务表，多数是search_path的问题。库里有多个 schema 时，客户端展示的是当前search_path覆盖的范围。默认值往往是"$user", public，业务表如果建在biz这个 schema 下，默认就看不见。

连接属性里可以直接指定search_path，或者连上之后执行：

-- 查看当前搜索路径 SHOW search_path; -- 把业务 schema 放到最前面（仅对当前会话生效） SET search_path TO biz, public; -- 想让它对账号长期生效 ALTER ROLE app_user SET search_path TO biz, public;

临时SET只影响当前会话，断开重连就回到原样，这一点很多人试了一次以为没生效，其实是没重连验证。要长期改就落到角色上。

另一个细节是端口和协议。PostgreSQL 的 SSL 是通过连接参数协商的，服务端pg_hba.conf里如果某条规则写的是hostssl，走非 SSL 连接就会被直接拒绝，报错信息是no pg_hba.conf entry for host ...。这种报错字面上像是白名单问题，实际是加密要求没满足，看pg_hba.conf那一行的前缀是host还是hostssl就能分辨。

4. 数据传输、结构同步与定时备份：把重复劳动压成一次配置

客户端真正的效率杠杆不在写 SQL，而在那些每周都要做一遍的机械动作：把生产库某几张表搬到测试库、比对两套环境的表结构差异、每月初导出一份归档。这些活手工做一次十分钟，做一年就是几十小时，而且每次都会有细微差别。

4.1 传输向导里几个勾选框的真实含义

“工具 → 数据传输”的向导看着啰嗦，关键就几项：

• 目标已存在同名表时的处理：可以选择“添加”（自动改名）、“删除后重建”、“跳过”、“覆盖数据”。“添加”在反复传输时特别坑，跑三次就会得到orders、orders_1、orders_2三张表，清理起来很烦。做环境同步时选“删除后重建”更干净。
• 包含/排除对象：默认按整库传，务必手动勾选到表级。整库传输在生产环境下极危险，视图、存储过程、触发器都可能被一并覆盖，而触发器被覆盖后业务逻辑会静默改变，这种问题很难第一时间发现。
• 遇到错误继续：生产转测试时建议关掉，任何一张表失败就停下来看原因，别让半成品数据混进去。

传输性能方面，向导里有“每批提交行数”的设置，默认值偏保守。几十万行以上的表，把这个值调到 5000 到 10000，整体耗时能明显下降；但别一次开到十万，事务日志会顶到上限，报的是日志空间不足而不是传输失败，更具迷惑性。

我习惯先用这个向导跑一遍小样本（加个WHERE id < 10000的条件过滤），确认字段映射、字符集、时间类型都正常，再放开全量。时间字段的时区偏移是最常见的隐性错误：源库存的是 UTC，目标库的会话时区是东八区，导过去整体差 8 小时，数据行数对得上，内容却是错的。

4.2 结构同步和数据同步不是一回事

“结构同步”比的是 DDL：字段有没有、类型对不对、索引和默认值差异。它生成一份变更脚本给你预览，可以逐条勾选执行。这份预览别急着点“执行”，先看两件事——它会不会DROP掉目标库多出来的字段（有些版本默认勾选删除），以及字符集和排序规则有没有被改成默认值。生产库上跑一次误删字段，恢复成本极高。

“数据同步”比的是行内容，它靠主键或唯一键做匹配，算出 INSERT / UPDATE / DELETE 三类语句。前提是两边表必须有可比的主键，没有主键的表会被跳过或者全量插入。有个细节：它默认只比对“目标表已存在”的对象，源库新增的表不会自动建，需要先跑一次结构同步。

两个功能都支持保存成“配置文件”，下次直接调用。这也是把日常操作固化的正确姿势：配置存下来，参数就不会每次凭记忆重填。

4.3 用外部脚本补上定时备份这一环

12.x 的计划任务（批处理作业）能做定时导出，但它依赖客户端进程常驻，机器一重启、账号一注销，任务就静默不跑了，而且失败了不一定有告警。备份这种不能出错的事，我一般交给系统级计划任务加命令行工具，客户端只负责人工核对。

#!/usr/bin/env bash # backup.sh —— 按库分别备份，压缩后保留 7 天 set -euo pipefail HOST="10.0.0.11" USER="backup_ro" PASS="从环境变量读，不要硬编码" DBS=("shop" "crm" "report") OUT="/data/backup/mysql" STAMP=$(date +%Y%m%d_%H%M) mkdir -p "$OUT" for db in "${DBS[@]}"; do # --single-transaction 保证 InnoDB 表的一致性快照，且不锁表 # --quick 逐行读取，避免大表把内存吃满 # --set-gtid-purged=OFF 去掉 GTID 语句，恢复到其他实例时不冲突 mysqldump -h"$HOST" -u"$USER" -p"$PASS" \ --single-transaction --quick --default-character-set=utf8mb4 \ --set-gtid-purged=OFF --routines --triggers \ "$db" | gzip > "$OUT/${db}_${STAMP}.sql.gz" # 立即校验压缩包完整性，写坏了当天就能发现 gzip -t "$OUT/${db}_${STAMP}.sql.gz" done # 清理 7 天前的旧文件 find "$OUT" -name "*.sql.gz" -mtime +7 -delete

逻辑上分三段：导出、校验、清理。三段缺一段都会留下隐患——只导出不校验，压缩写到一半磁盘满了会得到一个能打开但截断的文件，等真需要恢复时才发现；不清理，磁盘迟早被撑爆。

参数上重点说三个。--single-transaction只对 InnoDB 有效，如果库里混着 MyISAM 表，快照一致性就保证不了，得改用--lock-tables，代价是导出期间表被锁。--routines --triggers决定存储过程和触发器要不要一起备份，默认是不带的，恢复出来的库业务逻辑会缺一块。--set-gtid-purged=OFF在开启了 GTID 的实例上很关键，不加这个参数，导出的文件拿到另一个实例上恢复会直接报错。

密码硬编码在脚本里是常见做法也是最差的做法，改成从环境变量或者受限权限的配置文件读：

# 凭据放在只有属主可读的文件里，脚本启动时 source 进来 install -m 600 /dev/null /etc/mysql-backup.env # 文件内容形如：export MYSQL_PWD='xxxx' source /etc/mysql-backup.env

MYSQL_PWD环境变量虽然被官方标为不推荐（其他进程可能读到），但比写在命令行上安全得多——命令行参数在ps里对所有用户可见。要更稳妥就用--defaults-extra-file指向一个 600 权限的配置文件。

最后把脚本挂进 crontab，并且让失败可见：

# 每天 02:30 执行，输出追加到日志；非 0 退出码时发告警 30 2 * * * /opt/scripts/backup.sh >> /var/log/mysql-backup.log 2>&1 || /opt/scripts/alert.sh "备份失败"

||后面的告警脚本是整个链条里最容易被省略、又最不该省的一环。没有告警的定时任务等于没有任务，因为它的失败是完全静默的。

5. 避坑：五个让人当场卡住的现场

5.1 报 2059 认证插件加载失败

现象：MySQL 8 实例，账号密码确认无误，客户端报Authentication plugin 'caching_sha2_password' cannot be loaded，换 Navicat 自带的其他连接方式依旧。

原因：12.x 这一代客户端内置的驱动不识别 MySQL 8 的默认认证插件。它不是密码错误，报错文案会误导人去反复核对密码。

解决：优先在连接属性里开 SSL，新插件在加密通道下才能完整协商；不方便开 SSL 的内网环境，把该账号改成mysql_native_password，改完必须FLUSH PRIVILEGES并断开重连。切忌在服务端全局把default_authentication_plugin改回旧值——这会影响之后新建的所有账号，是个不可逆的坑。

5.2 导出 CSV 用 Excel 打开全是乱码

现象：从查询结果导出 CSV，用 Excel 双击打开，中文全是方块或者问号；用文本编辑器打开却显示正常。

原因：Excel 默认按系统本地编码（简体中文环境是 GBK）解析 CSV，而导出文件是 UTF-8 无 BOM。文件本身没错，是打开方式不匹配。

解决：导出时选“带 BOM 的 UTF-8”，或者直接导成 Excel 格式而不是 CSV。已经生成的文件可以用一行命令补 BOM：

# 给 UTF-8 文件补上 BOM 头，Excel 就能正确识别 printf '\xEF\xBB\xBF' > /tmp/with_bom.csv && cat /tmp/data.csv >> /tmp/with_bom.csv

反过来，如果文件要喂给数据管道，千万别带 BOM，很多解析器会把 BOM 当成第一列字段名的一部分。

5.3 大表导出中途内存爆掉或者连接被掐断

现象：导出一张两千万行的表，进度条走到一半客户端无响应，或者报连接超时；小表完全正常。

原因：两个独立问题叠在一起。一是客户端默认把结果集整体读进内存再落盘，行数一多就顶到内存上限；二是连接空闲超时，长时间没有数据往返，中间的网络设备或服务端wait_timeout把连接断掉。

解决：导出时勾选“分批导出”，按主键区间切片；连接属性里把“保持连接间隔”从 240 秒改到 60 秒，让客户端定期发心跳。数据量再大就别用客户端了，直接上mysqldump --quick或者SELECT ... INTO OUTFILE在服务端落盘再传文件，效率差一个数量级。

5.4 时间字段是 0000-00-00，导入直接失败

现象：源库里有大量0000-00-00 00:00:00的历史脏数据，导到目标库时报Incorrect datetime value，整批中断。

原因：目标库开了严格模式（sql_mode含NO_ZERO_DATE、STRICT_TRANS_TABLES），零日期被视为非法值。源库能存是因为它没开严格模式。

解决：别为了导数据去关目标库的严格模式，那等于把脏数据合法化。正确做法是清洗，把零日期替换成 NULL 或者一个约定好的哨兵值：

-- 先在源库上确认影响范围，再决定怎么处理 SELECT COUNT(*) FROM orders WHERE created_at = '0000-00-00 00:00:00'; -- 方案一：改成 NULL（前提是字段允许 NULL） UPDATE orders SET created_at = NULL WHERE created_at = '0000-00-00 00:00:00';

如果业务上零日期有特定含义（比如“未生效”），要跟业务方确认映射关系再动，不能自己拍脑袋定。

5.5 便携版换个目录，连接列表全空

现象：把整个程序目录从 D 盘挪到 E 盘，打开后发现所有连接都没了；或者换一台机器，配置不跟随。

原因：配置写在%APPDATA%下而不是程序目录里，或者移动过程中丢了隐藏的配置文件夹。还有一种情况是程序目录没有写权限，客户端退回到用户目录写配置，看起来就像“配置丢了”。

解决：先确认配置到底落在哪——改一个连接名，搜一下用户目录下最近修改的文件。确定位置后，迁移时把整个配置目录一起拷走。长期方案是给程序目录明确授予当前用户的完全控制权限，避免权限不足导致的静默回退。定期把连接配置导出备份一次，成本一分钟，能省掉重建几十个连接的麻烦。

6. 逆向出 ER 图、迁移后对账、验收清单

6.1 从现网库逆向出可读的 ER 图

接手一个没有文档的库，看表结构最快的方式是逆向工程。选“模型 → 逆向工程”，指定连接和目标库，勾选要纳入的表，客户端会把 DDL 解析成实体关系图。几个让图从“能看”变成“能读”的动作：

按业务域分图层。几十张表铺在一张画布上没法看，先把订单、用户、商品各自圈成一个区域，再拉自动布局。外键关系会自动连线，但很多库压根没建物理外键，这种时候需要手工拉关系线——手工线的价值在于它记录的是业务上的关联，比物理外键更贴近真实语义。图存成.nmox之后可以随代码库一起提交，后来人接手时省掉大量翻表的时间。

6.2 迁移之后，行数对得上不代表数据对

迁移验收里最容易糊弄的一步是“行数一致就通过”。行数一致但内容错位的情况非常常见——字段顺序错、编码转换丢字符、时间偏移。写个脚本做双层校验：

# reconcile.py —— 跨库核对：先比行数，再比主键集合的校验和 import pymysql SRC = dict(host="10.0.0.11", port=3306, user="ro", password="***", database="shop", charset="utf8mb4") DST = dict(host="10.0.0.21", port=3306, user="ro", password="***", database="shop", charset="utf8mb4") TABLES = ["orders", "order_item", "customer"] # 按依赖顺序无关，只做核对 def fingerprint(conn, table, pk): """返回 (行数, 主键集合的 CRC32 聚合值)""" sql = (f"SELECT COUNT(*), COALESCE(SUM(CRC32(`{pk}`)), 0) " f"FROM `{table}`") with conn.cursor() as cur: cur.execute(sql) return cur.fetchone() def main(): src = pymysql.connect(**SRC) dst = pymysql.connect(**DST) bad = 0 for t in TABLES: pk = "id" # 默认主键名，不一致的单独传 a = fingerprint(src, t, pk) b = fingerprint(dst, t, pk) status = "OK" if a == b else "DIFF" if a != b: bad += 1 print(f"{t:<12} src={a} dst={b} {status}") src.close(); dst.close() return bad if __name__ == "__main__": raise SystemExit(1 if main() else 0)

这段脚本只做了一件事：比行数和主键集合的指纹。CRC32 求和有个天然缺陷——顺序无关，而且不同主键值撞 CRC 的概率不为零，所以它能证明“主键集合大概率一致”，证明不了“内容一致”。要更严格就把关键业务字段拼进去：

# 把业务字段拼进指纹，字段顺序固定，NULL 用哨兵值替换避免拼接歧义 COLS = "COALESCE(`order_no`,'~'), COALESCE(`amount`,'~'), COALESCE(`status`,'~')" sql = (f"SELECT COUNT(*), COALESCE(SUM(CRC32(CONCAT_WS('#', {COLS}))), 0) " f"FROM `{table}`")

注意CONCAT_WS遇到 NULL 会跳过该字段，导致不同行拼出相同字符串，所以一定要先COALESCE成哨兵值。这个细节不做，校验会假阳性通过。

脚本的退出码给了1，是为了能直接挂进 CI 或者发布流水线：对账不通过，发布就卡住。这比人工看一眼报表可靠得多。

6.3 一份能直接照着走的验收清单

自增起始值这一项特别容易漏。数据导过去了，但目标库的自增计数器还停在 1，第一次插入就撞主键。修法很简单：

-- 把自增起点推到当前最大值之后，留出余量 ALTER TABLE orders AUTO_INCREMENT = 5000001;

这类问题的共性是：数据搬完那一刻一切正常，业务一跑起来才炸。所以验收不能只看“现在对不对”，还要想一遍“写操作进来会怎样”。

我吃过一次亏，迁移完对完行数就通知业务上线，结果第二天早上订单表主键冲突刷了一屏告警——自增没调。从那以后，每次迁移收尾我都强制走一遍上面的清单，尤其是自增和索引这两行，宁可多花二十分钟，也不要在凌晨被电话叫起来。希望帮到你。

本文还有配套的精品资源，点击获取