简介这份文档面向需要借助 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-port54321/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 了去查服务是否启动、监听地址、防火墙规则、网络模式。这一步能挡掉相当一部分“看起来是数据库问题、其实是网络问题”的求助。第二层是认证层。端口通了还连不上就看服务端放不放你。客户端认证配置文件里有没有你这个来源地址的记录认证方式是什么账号在这台机器上允不允许登录。临时改成更宽松的认证方式验证一下能进就说明是配置问题改回来再精细放行。第三层是操作层。能连上、能登录但建库、导入、执行出问题这时候看的就不是连接了而是字符集、权限、方言、语句结构。下面这张对照表可以贴在工位上报错一出来先对号报错或现象大概率根因优先动作password authentication failed连接类型选错或账号无权核对连接入口与账号权限no ... entry for host客户端地址未放行改认证配置并重载连接超时网络不通或监听地址受限telnet 测端口查监听与防火墙中文乱码字符集/排序规则不一致按源库参数重建目标库导入报表不存在结构未导出或顺序错先执行建表部分执行卡死单事务语句过多分批提交拆函数脚本定位完之后还有一步验证别省连接成功后拿一条最简单的SELECT跑通再建库再导一张小表的数据逐级加码。别一上来就整库转储出了错连是哪一步崩的都说不清。字符集验证也一样建完库先插几条中文数据读出来看看比迁完几万行再发现乱码成本低得多。从那以后我每次做这类库迁移都会强制走一遍“先测端口、再验连接、小表试导、抽样比对”的流程一步不跳。血的教训是跳过任何一步后面都要用更多时间去补。希望这套排查顺序能帮你在下一次看到红框的时候少改几遍密码直接找到那一层的问题。本文还有配套的精品资源点击获取