国产K库连接与迁移实战：端口、字符集、排序规则和转储验证

简介：这份文档面向需要以图形化方式管理人大金仓数据库的开发与运维人员，围绕使用Navicat建立连接并完成日常操作展开，适合刚接触金仓、希望快速上手可视化工具的学习者。内容以1个docx文档交付，压缩包约1.62MB，涵盖Navicat功能简介、下载安装、新建连接、账号密码配置、连接验证、创建数据库、转储SQL文件、复制为插入语句及执行SQL语句等模块，并提示排序规则与字符集一致性、账号权限和密码安全等注意事项。已有1300人学习，说明该主题在国产数据库工具适配场景中具有一定参考需求。读者可据此梳理从连接到库表操作的完整流程，理解数据备份迁移与SQL调试的常见做法，减少因字符集不一致导致的乱码等问题，也可作为团队内部培训或操作手册的素材。

1. 通用客户端连国产 K 库：先确认协议入口，再谈数据库 SQL 怎么写

第一次用通用客户端连国产 K 库，最容易翻车的不是数据库 SQL 写错，而是把连接当成常见开源库那套：端口随手填、库名留空、建库时默认排序规则，最后测试连接转圈，或者导进去的中文全变问号。K 库在兼容模式下能接受通用 SQL，但连接入口、默认端口、维护库名、字符集和排序规则都有现场差异。下面的步骤按“先验网络、再建连、再建库、最后迁移”展开，适合要做数据库迁移、临时查数、给业务同事开只读连接的从业者；新手照参数填能跑通，熟手重点看字符集和转储边界。

2. 建连参数拆解：主机、端口、库名和兼容模式怎么一次填对

2.1 客户端选型：多库管理省切换成本，但别把兼容当等价

通用数据库客户端的价值很直接：一套界面里管理多种库，连接配置、SQL 编辑器、结果集导出、结构对比、数据转储都在同一个窗口完成，不用在几个工具之间来回切。对经常做迁移的人来说，省下来的不是点鼠标的时间，而是少一次“这个库用哪条命令导、那个库用哪个参数连”的上下文切换。选型时我一般看三件事：协议入口是否明确、字符集和排序规则是否能在界面上看见、转储 SQL 时是否保留事务和序列信息。

但“能连上”不等于“完全等价”。K 库在兼容模式下能跑通用数据库 SQL，可系统函数、序列、权限模型、大小写处理仍有现场差异。建连前最好跟维护方要齐五样信息：主机、端口、维护库名、账号、兼容模式。只拿到主机和密码就开工，后面大概率要返工。尤其是初始数据库这一栏，很多客户端允许留空，但留空后连接落在哪个库并不确定，查不到表时人会先怀疑权限，实际只是连错了库。

我一般会把连接名按用途写清楚，比如demo_k_read、demo_k_migrate，而不是默认的“连接 1”。后面同时开生产只读、测试写、迁移临时库三个连接时，名字含糊就是给自己埋雷。连接配置里也别急着勾“保存密码”，共享机器上先把密码交给系统凭据管理，或者每次手输，省得后面排查认证问题时说不清是谁的会话。

2.2 安装包核对与驱动边界

客户端安装本身不复杂，坑多在安装前的版本核对。常见做法是从产品官方下载页拿安装包，先核对数字签名和哈希，再双击安装。安装路径尽量不含中文和空格，尤其是后面要调用命令行导出工具时，路径里带空格会让参数拼接多一层转义。旧版本没卸载干净时，新版本可能复用旧配置目录，表现是连接列表还在、驱动却加载异常，所以安装前先备份连接配置，再关掉所有客户端进程。

安装完成后别急着导入旧配置，先建一个最小测试连接。这里有个边界要提前知道：客户端内置驱动和服务器协议版本之间可能存在差异，表现不一定是“连不上”，而是连接成功但元数据加载很慢、表注释显示不全、某些对象类型看不到。遇到这种情况，先关掉“显示系统对象”和“显示日志对象”，再看加载速度。如果只是元数据慢，优先怀疑驱动和对象数量，不要一上来改服务器参数。

驱动边界还体现在字符集上。有些客户端在连接属性里单独放“编码”选项，默认值不一定是 UTF8。建连时先把编码显式设成和服务端一致，再保存连接。后面导入导出出现乱码，回头查配置时才能排除客户端这一层。安装包和驱动不需要追最新，现场验证过能稳定跑迁移的版本更值钱；升级客户端之前，先拿一个只读连接试元数据加载和转储，再动生产迁移连接。

2.3 新建连接参数表与测试顺序

新建连接时，我习惯先把参数写在表里，再往客户端里抄。这样出现连接失败时，能快速判断是参数错、网络错还是认证错，而不是在客户端弹窗里反复试。

参数表填完后，先在能访问数据库的跳板机上探端口，不要直接开客户端点“测试连接”。端口不通时，客户端只会给一个笼统的超时，排查方向容易被带偏。

# 在能访问数据库的跳板机上先探端口，替换成现场主机和端口 nc -vz 192.0.2.10 54321

这段命令的逻辑是先确认网络层和端口监听，-v输出详细过程，-z表示只探测不发送业务数据。端口探测失败时，先找网络或维护方确认监听地址、防火墙和白名单，不要反复改密码。端口通了再开客户端，测试连接只验证认证和初始库，不代表当前账号能看到业务表。登录后用一条最简单的查询确认身份：

-- 登录后先确认当前库、当前用户和当前模式 SELECT current_database() AS db, current_user AS login_user, current_schema() AS schema;

这条 SQL 的逻辑是把“我到底连到哪个库、用哪个账号、落在哪个模式”一次说清。参数上不需要改，直接执行即可；如果current_schema()不是业务表所在模式，后面查不到表就正常了，应该显式写public.t_order或切到对应模式，而不是怀疑数据没导进去。

注意：连接测试成功只说明网络和认证通了，不代表当前账号有业务表的查询权限。

2.4 账号权限与只读连接

给业务同事开只读连接时，不要直接把维护账号交出去。常见做法是单独建一个只读账号，只给连接、模式使用和查询权限，不给建表、删表、改数据权限。下面这段 SQL 是通用写法，库名、用户名和模式按现场替换，密码不要明文贴在共享文档里。

-- 只读账号授权示例，按现场库名、用户名和模式调整 CREATE USER app_ro WITH PASSWORD '现场密码占位'; GRANT CONNECT ON DATABASE appdb TO app_ro; GRANT USAGE ON SCHEMA public TO app_ro; GRANT SELECT ON ALL TABLES IN SCHEMA public TO app_ro; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO app_ro;

这段 SQL 的逻辑分四层：先建账号，再允许连接指定库，然后允许使用指定模式，最后给现有表和后续新表查询权限。参数上要注意ALTER DEFAULT PRIVILEGES只影响执行之后创建的表，历史表还是要靠GRANT SELECT ON ALL TABLES补。授权完成后让业务方自己登录一次，执行SELECT current_user;确认拿到的不是维护账号，再开始查数。

只读连接还要注意连接数。客户端默认可能开多个会话，报表工具再一接，很容易把连接池占满。建连时把“最大连接数”和“保持连接”调小，查询超时单独设，不要用连接超时兜底。遇到“连接数超限”时，先看客户端开了几个窗口，再看服务端当前会话，不要直接重启数据库。

3. 建库与字符集：排序规则选 C 还是本地化，先用三条 SQL 定基线

3.1 字符集、排序规则和模板库的关系

建库时最容易被忽略的是排序规则。编码决定“中文能不能存”，排序规则决定“中文怎么比、怎么排”。UTF8 只说明字符集能覆盖中文，不代表排序行为符合业务预期。C 排序规则按字节比较，速度快、跨平台一致，适合做迁移中间库和以主键查询为主的业务表；本地化排序规则按语言习惯比较，中文排序更接近拼音或区域习惯，但依赖操作系统 locale，跨环境迁移时容易出现“同一条 SQL 在两边排序不同”的问题。

模板库的作用是决定新库从哪个模板复制系统对象。用空模板库建库，可以避免把旧库的残留对象带进来，也更容易指定不同的编码和排序规则。常见做法是建迁移中间库时用空模板库加 C 排序规则，建业务正式库时先抄源库的编码、排序规则、字符类型三项，再决定要不要本地化。不要只看“编码是 UTF8”就认为两边一致，排序规则不同，索引顺序和查询结果顺序都可能不同。

我一般会在建库前先跑三条基线查询，把当前实例的编码、排序规则、字符类型抄下来。后面建库、建表、导入导出都对照这三项，出现乱码时才有对照物。

-- 建库前先确认当前实例的编码和排序基线 SHOW server_encoding; SHOW lc_collate; SHOW lc_ctype;

这三条命令分别看服务端编码、排序规则、字符分类。参数上不需要改，直接执行；如果客户端显示的结果和源库不一致，先不要建库，先确认是不是连到了另一个实例。很多“迁移后乱码”不是导入脚本的问题，而是建库时排序规则和源库不同，客户端又按另一套编码解释数据。

提示：建库前把源库的编码、排序规则、客户端编码三项抄下来，后面每一步都对照。

3.2 用 SQL 建库：显式指定编码和排序规则

客户端右键“新建数据库”很方便，但迁移场景我建议至少用一次 SQL 建库，把编码和排序规则显式写出来。图形界面里的默认值会随版本和现场配置变化，SQL 写清楚后，别人复现时不用猜你当时点了哪个下拉框。

-- 建迁移中间库：UTF8 编码 + C 排序规则，按现场库名替换 CREATE DATABASE demo_k WITH ENCODING 'UTF8' LC_COLLATE = 'C' LC_CTYPE = 'C' TEMPLATE = template0;

这段 SQL 的逻辑是创建一个 UTF8 编码、按字节排序的中间库，TEMPLATE template0表示从空模板复制，避免继承旧库对象。参数上，ENCODING要和源库字符集兼容，LC_COLLATE和LC_CTYPE要成对考虑；如果现场要求中文拼音排序，就不要选 C，应该用现场验证过的本地化规则。建完库后重新连到新库，再跑一次基线查询确认没有落回默认值。

如果是业务正式库，建库前先问清楚“排序规则以谁为准”。源库是本地化规则、目标库用 C，数据能存进去，但ORDER BY中文列的顺序会变，分页查询和报表排序可能对不上。反过来，源库是 C、目标库用本地化规则，跨平台迁移时又可能因为操作系统 locale 不同导致索引行为差异。我的习惯是迁移中间库用 C 保证一致，正式库跟业务确认后再定，不在建库弹窗里随手选默认。

3.3 表级排序规则与迁移对照

库级排序规则定了之后，个别列还可以单独指定排序规则。比如订单号、编码类字段用 C 比较更稳定，客户名称需要拼音排序时再用本地化规则。列级排序规则只影响该列的比较和排序，不会改变整个库的编码，但建表时要写清楚，后面加索引也要保持一致。

-- 表级示例：编码列用 C，名称列按现场需要选择排序规则 CREATE TABLE public.t_order ( id bigint PRIMARY KEY, order_code varchar(64) COLLATE "C" NOT NULL, customer_name varchar(80) NOT NULL, created_at timestamp NOT NULL DEFAULT now() );

这段 SQL 的逻辑是把订单编码列固定为 C 排序，保证编码比较不受 locale 影响；客户名称列不写列级排序规则，继承库级设置。参数上，COLLATE "C"在不同兼容模式下写法可能略有差异，执行前先在测试库验证；如果建表报排序规则不存在，说明当前库没有这个规则，应该回到建库步骤检查，而不是硬改列定义。

迁移前我会做一张对照表，把源库和目标库的库级编码、排序规则、字符类型、客户端编码四项并排记下来。导入完成后逐项核对，任何一项不一致都先停下来。乱码问题一旦写进业务表，后面要靠备份和重导解决，越早对照越省事。

4. 转储与批量写入：SQL 文件、复制为 INSERT、事务执行的三条边界

4.1 转储 SQL 文件的三种模式与适用场景

客户端里的“转储 SQL 文件”通常有三种模式：仅结构、仅数据、结构与数据。迁移时不要一上来就选“结构与数据”，先分清目标库是空库还是已有部分表。空库迁移可以结构和数据一起导，已有表补数据就只导数据，结构变更单独走变更脚本。选错模式的后果不是报错，而是重复建表失败或者数据覆盖，排查时还以为文件坏了。

转储前先确认目标库字符集和客户端编码一致，导出文件用 UTF-8 无 BOM。带 BOM 的 SQL 文件在部分客户端里第一行会多出不可见字符，执行时报“语法错误”，肉眼还看不出来。文件大时不要用编辑器打开，直接用客户端“运行 SQL 文件”，并关掉自动提交，先让它跑在一个事务里，出错能回滚。

转储文件里常见的SET语句、注释和空行不影响执行，但涉及序列、自增、权限的语句要单独检查。迁移中间库可以不带权限，正式库要确认序列当前值是否同步。转储完成后别只看“执行成功”，抽三张表对行数，再看主键最大值，避免数据截断。

4.2 复制为 INSERT 的边界：NULL、空串和转义

“复制为 INSERT”适合小批量补数，比如从查询结果里挑几十行搬到另一个环境。它的边界很清楚：结果集越大，生成的文件越难维护；字段里有单引号、换行、反斜杠时，手工复制容易漏转义。我一般只把它用于临时核对，批量迁移还是走 SQL 文件或脚本生成。

下面这段 Python 脚本把 CSV 转成 INSERT 语句，重点处理 NULL 和单引号转义。空串和 NULL 在业务上不是一回事，脚本默认空串保留为空串，只有字段缺失或显式标记才输出 NULL。

import csv def sql_literal(value): # None 输出 NULL；空串保留为空串，避免把业务空值误写成 NULL if value is None: return "NULL" text = str(value).replace("'", "''") return f"'{text}'" with open("t_order.csv", newline="", encoding="utf-8-sig") as f: reader = csv.DictReader(f) for row in reader: cols = ", ".join(row.keys()) vals = ", ".join(sql_literal(row[k]) for k in row.keys()) print(f"INSERT INTO public.t_order ({cols}) VALUES ({vals});")

这段脚本的逻辑是逐行读取 CSV，把每个字段转成 SQL 字面量，再拼成 INSERT。参数上，encoding="utf-8-sig"用来处理带 BOM 的 CSV，导出前最好统一成无 BOM；replace("'", "''")只处理单引号，如果字段里有换行，还要确认目标库和客户端能接受多行字符串。时间戳字段按文本插入会依赖隐式转换，严格场景应该显式写to_timestamp或先在脚本里格式化。

复制为 INSERT 后不要直接全量执行，先抽十条在测试库跑，确认 NULL、空串、时间戳、布尔值都符合预期。生产库执行前关掉自动提交，按主键分批提交，单批不要太大。遇到主键冲突时，先判断是重复导入还是源数据本身重复，不要一律改成覆盖写。

4.3 批量执行 SQL 文件的事务与编码

批量执行 SQL 文件时，事务边界比语句本身更重要。整个文件一个事务，出错回滚干净，但大文件回滚代价高；每批一个事务，速度快，但中途失败会留下部分数据。我一般按表分批：字典表先跑，主表再跑，子表最后跑，每批控制在几千行，批间记录最大主键，失败后从断点续跑。

-- 批量执行示例：先开事务，按依赖顺序插入，出错回滚 BEGIN; INSERT INTO public.t_dict (code, name) VALUES ('A', '测试字典A') ON CONFLICT (code) DO NOTHING; INSERT INTO public.t_order (id, order_code, customer_name) VALUES (1001, 'ORD-1001', '测试客户A'); -- 确认无误后提交；中途报错执行 ROLLBACK; COMMIT;

这段 SQL 的逻辑是先开事务，字典表用冲突忽略保证可重复执行，主表按主键插入，最后提交。参数上，ON CONFLICT的冲突列要跟唯一约束一致，没有唯一约束时不要硬写；BEGIN和COMMIT之间不要夹建库、建表这类不能回滚的操作。批量文件里如果带DROP TABLE，先确认目标库不是生产库，再执行。

编码问题在批量执行时最容易被忽略。客户端 SQL 编辑器有独立编码设置，文件本身也有编码，两边不一致时中文常量会乱码。执行前先跑一条SELECT '中文测试';，结果显示正常再跑业务 SQL。导入完成后用行数和主键区间双重校验，别只看客户端提示“执行成功”。

5. 连接与乱码排查：五条翻车记录，从端口探测到 BOM 头

5.1 网络与认证类问题

第一条血泪经验是“测试连接超时”。现象是客户端转圈十几秒后提示连接失败，换账号也一样。原因通常不是密码，而是端口填错、服务没监听在客户端能访问的地址，或者中间防火墙没放行。解决顺序是先用nc -vz探端口，再让维护方确认监听地址和白名单。端口不通时不要反复改连接参数，改到最后连自己填过什么都忘了。

# 端口探测：先确认网络层，再回客户端改参数 nc -vz 192.0.2.10 54321

这段命令只验证 TCP 端口是否可达，-v看详细输出，-z不发送数据。探测成功但客户端仍失败，再查认证和初始库；探测失败就直接找网络，不要在生产库上反复试密码，避免账号被锁。

第二条是“密码正确但认证失败”。现象是同一账号在命令行工具能连，客户端却报认证错误。原因可能是账号限制了来源地址、密码加密方式不匹配、初始库名大小写不对，或者连接串里多带了不支持的参数。解决时先用最小参数建连：主机、端口、库名、账号、密码，其他选项全关。连上后再逐项加 SSL、兼容模式、字符集。客户端日志里如果只有“认证失败”，让维护方看服务端认证日志，比在客户端猜快得多。

5.2 对象可见性与字符集问题

第三条是“连上了但看不到表”。现象是连接测试成功，左侧对象树只有系统对象，业务表一个没有。原因多半是当前库或当前模式不对，也可能是账号只有连接权限没有查询权限。解决时先跑SELECT current_database(), current_user, current_schema();，确认库、用户、模式三项；查表时显式写public.t_order，不要依赖默认搜索路径。如果显式写模式能查到，就是搜索路径问题；如果还查不到，再查权限。

-- 连接后确认身份和模式，排查“看不到表” SELECT current_database() AS db, current_user AS login_user, current_schema() AS schema;

这条 SQL 不依赖具体业务表，登录就能跑。参数上不需要改；如果结果里的库不是业务库，回连接配置改初始数据库；如果模式不是业务模式，查询时加模式前缀或执行SET search_path。权限问题让维护方在服务端查，不要用超级账号长期替代。

第四条是“建库后中文乱码”。现象是导入前查询正常，导入后中文变问号或方块。原因可能是库级编码和排序规则不一致、客户端编码不是 UTF8、SQL 文件带 BOM，或者导入时用了错误的字符集解释。解决时先跑SHOW server_encoding;和SHOW client_encoding;，两边都确认 UTF8；再把 SQL 文件转成 UTF-8 无 BOM，重新导入到测试库验证。不要直接在乱码表上改字符集，先备份再重导。

5.3 转储与批量执行问题

第五条是“转储 SQL 执行到一半报主键冲突或序列未同步”。现象是数据文件执行到某张表失败，或者插入成功但后续新增记录主键冲突。原因可能是目标表已有数据、转储文件重复执行、序列当前值落后于最大主键。解决时先确认目标表是否该清空，能清就备份后清空重导；不能清就用ON CONFLICT跳过或更新。序列同步要单独做，下面只是示例，序列名按现场替换。

-- 序列同步示例：把序列当前值推到最大主键之后 SELECT setval('public.t_order_id_seq', (SELECT max(id) FROM public.t_order));

这段 SQL 的逻辑是把序列当前值设置为表内最大主键，避免下一条插入撞主键。参数上，序列名必须和现场一致，setval的第三个参数默认表示下一次取下一个值；如果序列名写错会直接报错，不会悄悄改错对象。执行前先备份，生产库让维护方复核。

转储文件执行失败时，先看错误行号附近的语句，再看文件编码和事务边界。大文件不要用编辑器另存，另存可能改变换行符和编码。批量执行前先在测试库跑一遍，记录每张表行数和最大主键，生产执行后对照，别只看客户端最后一句“完成”。

6. 迁移后的验证：用行数、主键区间和编码快照把结果钉死

迁移完成后，我一般不让业务方先连，而是自己跑一轮验证。验证不复杂，三条 SQL 就够：一条看连接身份和编码快照，一条对关键表行数，一条看主键区间和空值。行数对不上时先别急着重导，先确认源库查询条件是否带过滤、目标表是否有触发器、导入是否中途失败。主键区间能快速发现截断，编码快照能排除客户端解释差异。

-- 1. 连接身份与编码快照 SELECT current_database() AS db, current_user AS login_user, current_schema() AS schema, current_setting('server_encoding') AS server_encoding, current_setting('client_encoding') AS client_encoding; -- 2. 关键表行数对照 SELECT 't_order' AS table_name, count(*) AS row_cnt FROM public.t_order UNION ALL SELECT 't_dict', count(*) FROM public.t_dict; -- 3. 主键区间与空值检查 SELECT min(id) AS min_id, max(id) AS max_id, count(*) FILTER (WHERE id IS NULL) AS null_id FROM public.t_order;

第一段确认当前库、用户、模式和两端编码，current_setting读的是会话级参数，客户端编码不一致会在这里露出来。第二段用UNION ALL把多张表行数并成一列，适合快速对照；表多时拆成多条执行，避免一条 SQL 跑太久。第三段看主键最小值和最大值，FILTER统计空主键数量，空值不为零说明导入时约束没生效或数据源有问题。

我还会做一张小校验表，把“源库行数、目标库行数、源库最大主键、目标库最大主键、编码是否一致”五项并排记录。任何一项不一致，先停下来查，不要用“大概齐”说服自己。迁移这种事，后悔药很贵，验证 SQL 很便宜。从那以后我每次接新库，都先把端口探测、编码快照、行数校验这三件事跑一遍，再让业务方连。希望帮到你。

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