简介Navicat Premium v12.1.17x64绿色中文注册版面向数据库开发、运维及同时连接 MySQL、Oracle 等数据库的学习者提供解压即用的图形化环境适合本地快速搭建查询调试工作区。压缩包共118个文件约92.21MB以dll动态库为主配合exe主程序、php脚本、msi组件及pdf/txt说明文档覆盖主程序运行、数据库驱动和激活辅助等环节。已有1414人学习具备一定使用验证基础。包内保留多数据库连接所需的核心组件与备份文件方便体验多库统一管理、SQL编辑和数据传输也可作为排查驱动缺失、依赖问题的参考配套文档与激活辅助文件便于按需配置。整体适合希望低成本试用Navicat多库管理能力的中初级开发者和运维人员。1. 一台机器上同时连 MySQL、Oracle、SQL ServerNavicat 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 为例字段填什么常见错误连接名自定的标识建议带环境前缀如prod-order-ro全叫“localhost”后面分不清哪个是生产主机IP 或域名不要带jdbc:前缀复制了 Java 的 JDBC URL 直接粘进来端口MySQL 3306、Oracle 1521、SQL Server 1433、PG 5432容器映射到高位端口后忘了改用户名/密码建议单独建只读账号做日常查询直接用 root误操作没有兜底数据库可留空连上再选Oracle 这里填的是 Service Name不是库名表单右侧一般有个“高级”页签里面几项值得改字符集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%和applocalhost是两个不同账号从别的机器连过来匹配的是前者。查一下-- 确认账号的 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_LANGSIMPLIFIED 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 HOST10.0.0.11 USERbackup_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-purgedOFF 去掉 GTID 语句恢复到其他实例时不冲突 mysqldump -h$HOST -u$USER -p$PASS \ --single-transaction --quick --default-character-setutf8mb4 \ --set-gtid-purgedOFF --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-purgedOFF在开启了 GTID 的实例上很关键不加这个参数导出的文件拿到另一个实例上恢复会直接报错。密码硬编码在脚本里是常见做法也是最差的做法改成从环境变量或者受限权限的配置文件读# 凭据放在只有属主可读的文件里脚本启动时 source 进来 install -m 600 /dev/null /etc/mysql-backup.env # 文件内容形如export MYSQL_PWDxxxx source /etc/mysql-backup.envMYSQL_PWD环境变量虽然被官方标为不推荐其他进程可能读到但比写在命令行上安全得多——命令行参数在ps里对所有用户可见。要更稳妥就用--defaults-extra-file指向一个 600 权限的配置文件。最后把脚本挂进 crontab并且让失败可见# 每天 02:30 执行输出追加到日志非 0 退出码时发告警 30 2 * * * /opt/scripts/backup.sh /var/log/mysql-backup.log 21 || /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(host10.0.0.11, port3306, userro, password***, databaseshop, charsetutf8mb4) DST dict(host10.0.0.21, port3306, userro, password***, databaseshop, charsetutf8mb4) TABLES [orders, order_item, customer] # 按依赖顺序无关只做核对 def fingerprint(conn, table, pk): 返回 (行数, 主键集合的 CRC32 聚合值) sql (fSELECT COUNT(*), COALESCE(SUM(CRC32({pk})), 0) fFROM {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 (fSELECT COUNT(*), COALESCE(SUM(CRC32(CONCAT_WS(#, {COLS}))), 0) fFROM {table})注意CONCAT_WS遇到 NULL 会跳过该字段导致不同行拼出相同字符串所以一定要先COALESCE成哨兵值。这个细节不做校验会假阳性通过。脚本的退出码给了1是为了能直接挂进 CI 或者发布流水线对账不通过发布就卡住。这比人工看一眼报表可靠得多。6.3 一份能直接照着走的验收清单检查项怎么查不通过的表现表数量与表名对information_schema.tables计数比对少表、多了备份表行数脚本批量比对差距集中在带软删除的表主键/唯一键指纹上面的对账脚本行数一致但指纹不同说明内容错位字符集与排序规则SHOW TABLE STATUS看 Collation中文排序结果和生产不一致索引完整性对比SHOW INDEX查询突然全表扫描慢查询暴涨自增起始值AUTO_INCREMENT字段新写入直接主键冲突时间字段时区抽十条样本人工核对整体偏移固定小时数视图与存储过程逐个SHOW CREATE比对业务报表数据对不上自增起始值这一项特别容易漏。数据导过去了但目标库的自增计数器还停在 1第一次插入就撞主键。修法很简单-- 把自增起点推到当前最大值之后留出余量 ALTER TABLE orders AUTO_INCREMENT 5000001;这类问题的共性是数据搬完那一刻一切正常业务一跑起来才炸。所以验收不能只看“现在对不对”还要想一遍“写操作进来会怎样”。我吃过一次亏迁移完对完行数就通知业务上线结果第二天早上订单表主键冲突刷了一屏告警——自增没调。从那以后每次迁移收尾我都强制走一遍上面的清单尤其是自增和索引这两行宁可多花二十分钟也不要在凌晨被电话叫起来。希望帮到你。本文还有配套的精品资源点击获取