Navicat连接人大金仓：认证失败、字符集与SQL迁移排查指南

简介：这份文档面向需要借助 Navicat 连接和管理人大金仓数据库的开发者、运维人员及数据库初学者，重点解决连接配置、日常建库、数据备份迁移与 SQL 调试中的常见问题。资源包仅含 1 个 docx 文档，压缩后约 1.62MB，结构精简，适合按目录快速定位所需操作。内容从 Navicat 的功能介绍、官网下载与安装程序说明讲起，随后依次说明新建连接、填写服务器地址与端口、配置账号密码、连接成功后的表与视图查看，以及创建数据库、转储 SQL 文件、复制为插入语句、在编辑器中执行 SQL 等常用流程。文中还提醒排序规则和字符集应与目标库保持一致，建议采用 C 字符集，并补充官方图形工具选择、账号权限与密码保护等注意事项。已有 1300 人学习，可为希望快速上手人大金仓图形化管理、梳理 SQL 备份迁移和语句执行思路的读者提供一份紧凑的操作参考。

1. 连人大金仓报错：明明账号密码没错，Navicat 就是提示连接失败

“连接失败”“FATAL: password authentication failed”“no pg_hba.conf entry for host”这几个提示，只要做过国产库迁移的人大概率都遇到过。账号密码反复核对无误，端口也通，ping 能过、telnet 能连，但 Navicat 一点“测试连接”就弹红框。这类问题折腾人的地方在于：报错信息把“认证失败”和“网络不通”混在一起说，你按账号问题查半天，最后发现是库类型选错、字符集不匹配，甚至根本不该用这个连接方式。这份资料围绕“用 Navicat 连人大金仓”这条链路，把建连接、配账号、建库、转储 SQL、执行语句这些动作串成一条可复现的排查路径，适合正在做数据库迁移、被乱码和认证报错卡住的开发者，也适合第一次接触这类兼容型数据库、想先把连接打通再谈后续操作的同学。

2. 连接建不起来：四类典型报错与逐层定位

人大金仓在协议层面对 PostgreSQL 有较强的兼容性，所以 Navicat 里选什么数据库类型、填什么端口、走不走 SSL，直接决定了你看到的是“认证失败”还是“连接超时”。很多教程只写“新建连接、填地址密码、点确定”，但真到报错那一步，缺的恰恰是“这一步为什么会失败、失败了先看哪”。下面按报错出现的先后顺序拆。

2.1 报 “password authentication failed”：先怀疑库类型选错

最常见的一类翻车是这样的：在 Navicat 里新建连接时，下拉框随手选了 MySQL 或者“PostgreSQL”里某个不匹配的选项，填完 IP、端口、账号密码，点测试，直接弹认证失败。人看到“密码错误”四个字就去改密码，改了三遍还是失败，其实问题根本不在密码。

根因在于连接握手阶段用的协议和驱动不对。人大金仓对外表现更接近 PostgreSQL 系列，认证方式、系统表结构、SQL 方言都按这个体系走；如果你把它当成 MySQL 去连，服务端收到的握手包格式就不对，返回的自然是一句含糊的认证失败。正确的做法是在新建连接时明确选择与人大金仓兼容的类型（多数版本在 Navicat 里走 PostgreSQL 连接入口），端口填数据库实际监听的端口，而不是想当然填 3306。

# 先在服务器侧确认端口和监听状态，别急着在客户端反复试 # 查看数据库进程实际监听的端口（默认端口以实际部署为准） netstat -tlnp | grep -i kingbase # 或者用 ss 查看 ss -tlnp | grep -i kingbase # 客户端侧先测端口通不通，排除网络层问题 telnet 192.168.1.100 54321

上面这段的作用是把“网络层”和“认证层”分开。netstat -tlnp里-t看 TCP、-l只看监听、-n用数字显示端口、-p带出进程名，能一眼确认数据库到底在哪个端口上等着；telnet那条是粗测端口可达性，能连上说明网络和防火墙不是主因，连不上就先别折腾账号，去查防火墙和监听地址。这两步做完，你再回到 Navicat 填连接信息，心里就有底了：端口对不对、服务在不在，一目了然。

顺手提一句，如果netstat显示监听地址是127.0.0.1而不是0.0.0.0，那从别的机器连必然失败，这跟密码一点关系都没有。这种情况要么改数据库的监听配置，要么就在本机操作，别在客户端死磕。

2.2 报 “no pg_hba.conf entry for host”：客户端地址没被放行

这个报错比上一个直白，但很多人看到pg_hba.conf就懵——人大金仓里对应的是它自己的客户端认证配置文件，名字和路径跟原生 PostgreSQL 不完全一样，思路是一致的：服务端有一张“允许哪些来源、用哪种认证方式”的清单，你的客户端 IP 不在清单里，或者清单里给它分配的是reject，连接就会被挡在认证之前。

常见做法是找到数据库实例的配置目录，编辑客户端认证配置文件，为目标网段加一条放行记录，然后让配置生效。这里要注意认证方式的选择：trust表示完全信任、不校验密码，图省事可以临时用，但生产环境别这么干；md5或scram才是常规选择。改完必须重载配置，否则改了个寂寞。

# 找到实例的配置目录（路径以实际安装为准，通常在 data 目录下） # 编辑客户端认证配置文件，追加一行放行记录 # 格式：连接类型 数据库 用户 来源地址 认证方式 host all all 192.168.1.0/24 md5 # 重载配置，让改动生效（不同版本命令略有差异，以实际为准） # 方式一：在数据库内执行重载 # 方式二：通过服务管理命令重启实例

格式那一行四个字段是关键：host表示走 TCP 连接，all表示所有库、所有用户，192.168.1.0/24是放行的网段，最后是认证方式。改完不重载，配置不会进内存，你会以为改动没生效，其实是没让它读。我一般会先只放行自己这台机器的单个 IP，确认能连上，再放开网段，这样出问题时排查范围小。

注意：临时把认证方式改成trust能快速验证“是不是认证配置的问题”，但验证完立刻改回来。留着trust相当于门不上锁，属于给自己埋雷。

2.3 报连接超时：防火墙、监听地址与端口三选一

超时和认证失败是两种完全不同的体感：认证失败是“连上了但不让你进”，超时是“连招呼都没打上”。这时候别在 Navicat 里反复点测试，越点越焦虑，按顺序查三样东西。

第一查服务是否在跑；第二查监听地址是否只绑了本机；第三查中间有没有防火墙拦端口。前两步上面已经给过命令，第三步在 Linux 上通常是防火墙规则没放行，在 Windows 上则是安全组或本机防火墙。很多人在虚拟机里装库、宿主机上连，结果虚拟机的网络模式是 NAT，宿主机根本路由不过去，这种也算“超时”，但根因在网络拓扑，不在数据库。

# Linux 下查看防火墙放行情况并临时放行端口 # 查看当前规则（命令以实际发行版为准） firewall-cmd --list-ports # 放行数据库端口，--permanent 表示持久化，reload 让规则生效 firewall-cmd --add-port=54321/tcp --permanent firewall-cmd --reload

参数说明：--add-port后面是“端口/协议”，--permanent不加的话重启就失效，--reload是让新规则立刻生效而不是重启整个防火墙服务。放行完再回客户端测，通了就说明是防火墙的锅。如果放行了还不通，回头检查第二节说的监听地址，两件事经常是一起犯的。

2.4 建库时字符集和排序规则选错，后面全是乱码

连接打通只是开始，接下来建库这一步埋的坑更深。原文里有一句提醒很关键：排序规则和字符分类要和迁移源库保持一致，否则出现乱码，并建议使用C。这句话看起来轻描淡写，实际上是整条迁移链路上最容易翻车的地方。

乱码的典型表现是：数据导进去之后中文变成问号或者一堆方块，查询条件带中文查不出来，排序结果和源库对不上。根因是建库时字符集和排序规则跟源库不一致，数据在写入时按一套规则编码，读出时按另一套规则解码，自然对不上。人大金仓自带图形工具建的库默认可能是zh_CN.UTF-8这类本地化规则，而你在 Navicat 里建库时如果随手选了默认值，两边规则不一致，迁移就出问题。

-- 建库时显式指定字符集与排序规则，与源库保持一致 -- 库名、编码、排序规则按实际迁移需求调整 CREATE DATABASE target_db WITH ENCODING 'UTF8' LC_COLLATE = 'C' LC_CTYPE = 'C' TEMPLATE = template0;

逐项说：ENCODING 'UTF8'定编码，中文场景基本都用它；LC_COLLATE管排序比较规则，LC_CTYPE管字符分类（大小写、字符类型判断）；这两个都设成C的意思是按字节序做比较，行为最稳定、跨平台差异最小，迁移场景里不容易出意外。TEMPLATE = template0是为了避免继承模板库里已有的字符集设定，不写这句，有些环境会因为模板库规则冲突直接建库失败。

提示：建库前先查源库的编码和排序规则，照着抄，别凭感觉选。迁移完成后拿几条含中文、含特殊符号的数据做抽样比对，比迁完就宣布成功靠谱得多。

3. 连上之后还有坑：建库、转储与执行 SQL 的常见故障

连接通了，账号也对了，剩下的操作看起来都是点点鼠标的事，但恰恰是这些“看起来简单”的动作，在国产库迁移场景里最容易出问题。转储出来的 SQL 在目标库执行报错、复制出来的插入语句引号不匹配、执行大脚本直接卡死，这些都属于“看着能用、实际踩坑”的范畴。

3.1 转储 SQL 文件：导出成功但导入报错的三类原因

转储 SQL 文件是备份和迁移的常规动作，在 Navicat 里选中表或整个库，走右键菜单转储即可。问题往往出在导出的文件拿到目标库执行时：报语法错误、报表不存在、报字段类型不支持。这三类报错对应的根因完全不同。

语法错误多半是数据库方言差异。虽然人大金仓和 PostgreSQL 系兼容度高，但导出的脚本里可能包含目标库不认的写法，比如某些类型转换、自增列定义、序列调用方式。表不存在通常是导出时只导了数据没导结构，或者导入顺序不对——有外键依赖的表被随机顺序执行，先建子表后建父表必然失败。字段类型不支持则要看源库和目标库的类型映射，导出的varchar长度在目标端超限、timestamp精度不一致都会报。

# 导入前先看一眼脚本头部的结构定义，重点看三类内容 # 1. 建表语句里的字段类型和长度 # 2. 外键、索引、序列的创建顺序 # 3. 是否有目标库不支持的方言写法 head -n 80 dump_file.sql # 导入时把错误输出留下来，别让它一闪而过 # 在命令行侧执行导入并记录日志

head -n 80是快速抽样看结构，重点不是读完全文，而是确认建表部分有没有明显不对劲的类型。导入时留日志这个习惯很值：Navicat 的图形化导入提示往往只说“执行失败”，具体是第几条语句、什么错误号，得靠日志看。我一般会先把脚本里的建表部分单独拿出来执行，结构建好了再灌数据，这样出错时范围清晰。

3.2 复制为插入语句：引号和转义导致的手工迁移翻车

“复制为插入语句”是 Navicat 里一个很讨巧的功能，选中几行数据右键复制，生成INSERT语句粘贴到别处。小批量搬数据时确实快，但它生成的语句在跨库粘贴时经常执行失败，原因集中在转义上。

典型现象是：粘贴执行报字符串未正确结束，或者中文字段值变成乱码。根因是生成的插入语句里，字符串的引号和源数据里的单引号冲突了。数据里如果本身带单引号，比如“张三's 备注”，生成的语句可能没有正确转义，拼接后语法直接崩掉。另一种情况是字符集处理差异，复制出来的内容经过了剪贴板，某些控制字符或特殊符号走样。

-- 手工迁移数据时，优先用带转义的写法，别直接粘原始值 -- 数据里含单引号的场景，用两个单引号转义（SQL 标准写法） INSERT INTO target_table (id, name, remark) VALUES (1, '张三', '这是含 '' 单引号的备注'); -- 数据量稍大就别手工拼了，直接从文件导入更稳

转义规则值得记一下：SQL 里字符串常量用单引号包裹，值内部出现的单引号写成两个连续单引号，这是标准写法，兼容性最好。不过更实际的建议是：超过几十行的数据就别用“复制为插入语句”了，走转储文件或者批量导入，手工拼接的脚本越多，出错概率越大，而且很难核对我到底漏了哪一行。

3.3 执行 SQL 卡死或报错：事务、语句分隔与权限

在 Navicat 的查询窗口里贴一大段脚本，点运行，然后界面转圈半天没反应，或者只跑了一半就停住，这也是高频问题。原因通常有三个方向。

一是语句量大且没分批提交。几万条INSERT打包在一个事务里执行，日志暴涨、锁住大量资源，看起来就是卡死。二是语句分隔符问题。脚本里包含函数、存储过程这类带分号体的对象，在查询窗口一次性执行时，解析器会把函数体内的分号当语句结束符，导致语法错误。三是权限不足。账号能连上不代表能建表、能写数据，CREATE权限和INSERT权限是分开授予的，报权限错误时别怀疑密码，去查账号角色。

-- 确认当前账号有哪些权限，先搞清楚自己能干什么 -- 查看当前用户的角色与权限（具体视图名以实际库为准） SELECT current_user; -- 大脚本分批执行，别一个事务顶几万行 -- 每批控制在一个合理的行数，提交一次 BEGIN; -- 一批 INSERT ... COMMIT;

SELECT current_user是最快的自检，先把“我是谁”弄清楚，再去对权限清单。分批提交的思路是：每个事务的语句数控制住，比如几百到一千条一批，BEGIN和COMMIT成对出现。这样即使中途失败，已提交的部分还在，不用从头再来。至于带函数体的脚本，建议单独拆出来执行，或者用支持自定义分隔符的方式处理，别混在普通查询窗口里一起跑。

4. 避坑清单：五条踩过的坑和当时的解法

下面这些坑是我在实际迁移过程中反复遇到或看别人踩到的，每条都按“现象、原因、解决”记，遇到类似症状可以对照着查。

坑一：测试连接一直转圈，最后超时。现象是点测试后进度条走很久然后报失败。原因是客户端和服务端之间网络不通，或者服务端监听地址只有本机。解决是先telnet测端口，通了再查监听配置，把127.0.0.1改成对外地址或改走本机操作。

坑二：账号密码确认无误，仍然认证失败。现象是填了三遍密码都报错。原因是连接类型选错，把兼容 PostgreSQL 的库当成别的类型连。解决是回新建连接界面，换正确的数据库类型入口，端口填实际监听端口。

坑三：数据导入后中文全是乱码。现象是英文正常、中文变问号。原因是建库时字符集和排序规则与源库不一致。解决是按源库参数重建目标库，排序和字符分类统一用C，字符集用 UTF8，重建后重新导入。

坑四：转储的 SQL 在目标库执行一半报错。现象是前面几张表成功，到某张表报语法或类型错误。原因是方言差异或类型长度超限。解决是先单独执行建表部分，逐张表确认，把不兼容的字段类型手工调整后再灌数据。

坑五：查询窗口执行脚本没反应，界面卡住。现象是转圈很久或卡死。原因是超大批量语句单事务执行，或者脚本里混了带分号体的对象。解决是拆批次提交，函数类脚本单独跑，同时确认为账号授予了足够权限。

注意：这五条里，前两条和连接参数相关，中间两条和数据迁移相关，最后一条和执行方式相关。排错时先判断自己卡在哪一层，别把连接问题当成数据问题去修。

5. 快速定位：把报错分成三层，按顺序往下压

折腾多了之后，我处理这类连接和迁移问题有个固定顺序，基本能在一两轮内把范围压到最小，这里把它整理成可复用的判断路径。

第一层是网络层。任何报错先别读错误内容，先确认“这台客户端能不能摸到那台服务端”。telnet 目标IP 端口一条命令，通与不通直接把问题劈成两半。不通就别看 Navicat 了，去查服务是否启动、监听地址、防火墙规则、网络模式。这一步能挡掉相当一部分“看起来是数据库问题、其实是网络问题”的求助。

第二层是认证层。端口通了还连不上，就看服务端放不放你。客户端认证配置文件里有没有你这个来源地址的记录，认证方式是什么，账号在这台机器上允不允许登录。临时改成更宽松的认证方式验证一下，能进就说明是配置问题，改回来再精细放行。

第三层是操作层。能连上、能登录，但建库、导入、执行出问题，这时候看的就不是连接了，而是字符集、权限、方言、语句结构。下面这张对照表可以贴在工位上，报错一出来先对号：

定位完之后还有一步验证别省：连接成功后拿一条最简单的SELECT跑通，再建库，再导一张小表的数据，逐级加码。别一上来就整库转储，出了错连是哪一步崩的都说不清。字符集验证也一样，建完库先插几条中文数据读出来看看，比迁完几万行再发现乱码成本低得多。

从那以后我每次做这类库迁移，都会强制走一遍“先测端口、再验连接、小表试导、抽样比对”的流程，一步不跳。血的教训是跳过任何一步，后面都要用更多时间去补。希望这套排查顺序能帮你在下一次看到红框的时候，少改几遍密码，直接找到那一层的问题。

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