SQLark实战：轻松搞定达梦、Oracle、MySQL、PG数据库快速导入数据

SQLark 实战 | 如何快速导入数据至达梦、Oracle、MySQL、PG 数据库

做DBA和开发这些年，最烦的事情不是写SQL，而是倒数据。尤其是手里同时管着达梦、Oracle、MySQL、PG好几套库的时候，今天这个库要导个Excel，明天那个库要从另一套库抽数据，时间全耗在来回切换工具上了。后来换了SQLark，算是把这摊糟心事理顺了。这篇文章就从我实际使用的角度，把怎么用SQLark往达梦、Oracle、MySQL、PG这四类数据库里快速导入数据这件事讲透，包括操作步骤、参数怎么选、踩过哪些坑，希望能帮到你。

1. 为什么我最终选了SQLark来干这件事

1.1 数据库导入的日常痛点

我相信很多人都有类似的经历。以前往Oracle里灌数据，要么用PL/SQL Developer，要么写SQL*Loader脚本；往MySQL里导数据，又得换成Navicat或者命令行source；到了达梦和PG，又是另一套工具。每换一次工具，连接配置要重新搞一遍，导入格式要重新调，字符集问题更是家常便饭。

工具割裂带来的最大问题，不是多装了几个软件，而是心智负担。你要记住每个工具的快捷键、每个工具的导入向导长什么样、每个工具对CSV编码的默认处理方式。时间久了，连哪个按钮在哪儿都要想半天。再加上项目里经常做国产化替代，达梦库越来越多，老的工具支持度又跟不上，这时候一个能统一管四类库的工具就成了刚需。

我对比过DBeaver、DataGrip、Navicat，各有各的长处。DBeaver免费但界面糙，DataGrip对PG和MySQL友好但对达梦的支持一般，Navicat好用却不支持达梦。SQLark吸引我的点很直接：原生支持达梦，同时覆盖Oracle、MySQL、PG，一个客户端搞定四类库，导入功能也做得比较顺手。

1.2 SQLark的核心定位与选型考量

SQLark的定位是通用数据库管理工具，不是某个数据库的专属客户端。它既能做日常的库表浏览、SQL查询、对象管理，也能承担数据导入导出这类高频操作。它最核心的价值在于"统一"——连接管理统一、操作习惯统一、导入导出流程统一。

选型的时候，我还看中了它这几个点。第一，对达梦的适配做得比较深，毕竟是国产工具，对国产库的支持优先级天然更高。第二，导入功能不只是简单的Excel到表，它支持ODBC数据源、CSV文本、SQL脚本、甚至跨库直连导入多种方式，可以应付大多数真实场景。第三，界面设计贴近国内开发者的操作习惯，不像有些国外工具那样菜单层级很深，找选项要找半天。

当然，工具终究是工具，用得好不好还是看你对数据库本身的理解。SQLark能帮你省掉重复劳动，但不能替代你判断数据对不对、字段映射得对不对。下面我就从实际操作出发，把整个流程拆开讲。

2. 连接配置：一次性把四个库都搞定

2.1 下载安装与初始设置

SQLark的安装没什么好说的，基本就是下一步、下一步。装完以后需要注意一个点：首次启动会让你选择工作目录，这个目录用来存放连接配置、查询历史、导入导出临时文件。我建议单独建一个目录，别用默认的C盘路径，因为导入导出大文件时临时文件可能比较大，放在系统盘容易把C盘塞满。

初始设置里有两处值得关注。一是"连接空闲超时"，默认可能比较短，如果你经常挂着连接写复杂SQL，建议调长一点，不然写到一半连接断了，前面的思考全白费。二是"事务提交方式"，在导入大批量数据时，自动提交每条记录和批量提交之间性能差距明显，后面我会专门讲。

2.2 四类数据库的连接参数详解

新建连接的时候，SQLark会要求选择数据库类型，然后填写主机、端口、服务名/数据库名、用户名、密码。看起来简单，但四类库各有各的门道。

达梦数据库和Oracle有点类似，连接信息里除了主机和端口，还需要填服务名。达梦的默认端口是5236，不是常规的1521或3306，这个容易搞错。服务名一般在安装达梦时配置，如果记不住，可以去达梦安装目录下的dm.ini里查，或者问一下DBA。用户名建议用具有DBA权限的账号，比如SYSDBA，因为导入数据经常要建表、改表结构，权限不足会卡在半路。

Oracle的默认端口是1521，服务名通常是ORCL或者你自定义的实例名。有个小坑：如果目标库启用了CDB/PDB架构，你连接的时候要确认是连到CDB还是某个PDB，这决定了你能看到哪些表。连PDB的话，服务名要填PDB的名字，用户名也要是PDB里创建的用户，否则会报ORA-01017或ORA-12514。

MySQL和PG相对简单。MySQL默认端口3306，PG默认5432。需要注意的是PG的连接库名，默认连postgres库，如果想操作业务库，连接时要指定目标数据库名。MySQL这边如果用的是8.0以上版本，密码加密方式默认是caching_sha2_password，SQLark新版本应该都兼容，如果连接报认证插件错误，可以临时把用户密码改成mysql_native_password方式过渡一下。

把这些连接都建好之后，建议在连接名称上做好标记，比如"达梦-生产-核心库"、"MySQL-测试-订单库"，不要偷懒用默认的localhost、test之类。库一多，记录混乱了特别容易连错，导错数据可不是闹着玩的。

3. 核心实操：用SQLark快速导入数据的四种方式

3.1 从Excel和CSV文件导入

这是日常用得最多的场景。业务部门隔三差五丢过来一个Excel，说"帮我把这些数据导进库里"。以前我的做法是先用Excel转CSV，再用工具导入，Excel转CSV的时候还得注意编码，一个不小心乱码全出来了。

用SQLark操作是这样的：在左侧对象树里选中目标表，右键选择"导入数据"，在弹出的窗口里选择文件类型、文件路径，然后进入字段映射界面。SQLark支持xls和xlsx格式，也支持CSV和TXT，基本上覆盖了日常所有场景。

有几个关键设置必须讲清楚。

第一是"首行作为字段名"。如果Excel第一行就是列名，勾选这个选项后，SQLark会自动把列名和表字段做映射，省得你手动一个一个对。如果Excel里第一行就是数据，千万别勾，否则第一条数据会被当成字段名吞掉。

第二是"字段映射"。SQLark会根据表结构自动匹配同名同类型的列，匹配不上的会标红。比如Excel里有个"创建时间"，表里的字段叫"create_time"，这种不会自动匹配，需要你手动拖拽对应。还有些列是表里没有的，比如Excel里有个"备注说明"列，但表里没有对应字段，这时候你有两个选择：要么在映射界面直接删掉这一列的映射，导入时忽略它；要么先改表结构加上这个字段再导。我的建议是，临时导入数据就别改表结构了，直接忽略多余的列，省得留下垃圾字段。

第三是"数据起始行"。有时候Excel里前面几行是标题和说明，比如"XX公司2024年1月数据汇总"，这种要先看清楚，把起始行设为真正的数据行，否则会把标题行也导进去，查数据时一堆莫名其妙的脏数据。

编码这个坑单独说一下。CSV文件最怕编码不对。用Windows记事本另存的CSV默认是ANSI（GBK），而SQLark导入时默认可能按UTF-8去读，导致中文全部变成乱码。解决办法：如果发现预览区中文乱码，回到源文件，用Notepad++或VS Code重新保存为UTF-8编码（不带BOM最好），再重新导入。Excel另存为CSV时,选"CSV UTF-8"格式也可以避免这个问题。

3.2 从另一套数据库直接导入（跨库抽取）

SQLark另一个很实用的功能是数据库之间的数据复制，不需要中间文件。比如要把Oracle生产库的一张表同步一部分数据到达梦的分析库，或者把MySQL的数据抽到PG做测试，都可以直接操作。

操作路径：在SQLark里同时配置好源库和目标库的连接，然后在源库找到对应的表，右键选择"导出数据"或者直接在目标库执行INSERT INTO ... SELECT语句（前提是SQLark支持跨库查询）。我实际用的最多的是"导出到其他数据库"这个入口，流程大概是：

选择要导出的表（可以多选），选择目标连接和目标库，选择同步方式，然后执行。

同步方式里有一个很重要的选项：目标表不存在时自动建表。这功能在开发环境特别方便，源库表结构改了你不用手动去同步DDL，直接导数据时自动把表建出来。但要注意，自动建表只复制列名和数据类型，不复制主键、索引、触发器、存储过程这些对象。如果目标表需要完整结构，还得单独处理DDL脚本。

数据量大的时候，SQLark的批量提交机制就体现出优势了。比如往PG导100万条数据，你可以设置每个批次提交5000条。批次大小不是越大越好，太大的话事务日志会膨胀，而且一旦中途失败回滚的成本极高。我通常的做法是先测一个批次5000条看看耗时，然后根据情况调整到1万或减少到2000。达梦和Oracle类似，批量提交能显著减少redo日志的写入压力，导得快很多。

3.3 用SQL脚本批量执行导入

有些数据不是来自文件，而是现成的SQL脚本，比如从另一个库导出的INSERT语句。这时候用SQLark执行SQL文件就行。

导入SQL脚本时注意两点。第一是文件大小，如果SQL脚本超过几十MB，建议先检查一下里面的INSERT语句是不是一条一条写的，有没有人为改成批量INSERT。大批量单条INSERT语句执行起来非常慢，可以考虑用脚本处理工具把它们合并成多值INSERT（比如每条语句插入500行），这样执行效率提升好几个量级。第二是脚本里可能包含的SET DEFINE、SET ECHO之类的SQL*Plus控制命令，这些在SQLark里不一定能识别，执行前最好删掉或者改成SQLark兼容的写法。

执行脚本前，SQLark会有一个预览确认界面，你最好先仔细看一遍脚本内容，尤其是没有WHERE条件的DELETE或UPDATE语句——别问我是怎么知道要提醒这个的。

3.4 以达梦为例：完整导入演练

为了让你有更直观的参考，我用达梦库走一遍完整流程。

假设我手上有一个Excel文件，里面是10万条用户数据，字段有：用户ID、姓名、手机号、注册时间、状态。目标表是DM库里的T_USER。

第一步，先把Excel表头改简单一点，跟数据库字段对应上，比如"用户ID"改成"USER_ID"、"姓名"改成"USER_NAME"，这样SQLark自动映射成功率更高，省去手动拖拽的麻烦。

第二步，在SQLark左侧树里找到T_USER表，右键选导入数据，选择文件，下一页。在字段映射页面，检查列是否都对应上，把"注册时间"对应到REG_TIME，因为类型可能一个是文本一个是日期，SQLark会自动做转换，但你要确认格式对得上。

第三步，设置导入选项。我习惯把"事务提交方式"选为分批提交，每批2000条。不要把"出错继续"和"出错停止"搞混了，看你的需求：如果只是补数据，建议选"出错停止"，因为一旦出错说明数据有问题，继续导只会把更多脏数据导进去，后面清理更麻烦。

第四步，执行导入，看结果统计。SQLark导完会显示成功多少条、失败多少条，如果失败的，可以导出错误日志，看具体哪些行有问题。10万条数据，在达梦上分批发导入，一般几十秒内就能完成。

流程就是这么简单。但很多人一开始会忽略导入前的数据预览。SQLark在导入前会显示前100行的预览，一定要花一分钟看看。数据量一多，有些坑在生成文件时已经埋下了，比如某一行多了一个逗号、某一个日期格式不对，这些在预览时能发现就早点发现，省的导到一半报错。

4. 导入过程中常见的坑与排查思路

4.1 达梦数据库导入的典型问题

达梦这几年用得越来越多，但很多从Oracle转过来的人还是会踩到一些达梦特有的坑。

第一个坑是模式（Schema）的问题。Oracle里用户名和Schema基本是一一对应的，但达梦里一个用户可以访问多个模式。导入数据时，如果指定的目标表是"模式名.表名"这种格式，一定要确认模式名写对了。我遇到过好多次，数据导成功了但导到了默认模式（通常是SYSDBA）下，业务系统查不到数据，折腾半天才发现是模式和用户不匹配。

第二个坑是大小写敏感。达梦默认对表名和字段名不是大小写敏感的，但如果你在创建表时用了带双引号的标识符，它就会变成大小写敏感。导入生成目标表时，SQLark默认会保留原始大小写，这可能导致后续查询语句大小写不匹配查不到数据。解决办法是导入建表后，马上检查生成的建表语句，如果发现列名带了双引号且大小写不一致，提前处理。

第三个坑是非法字符。Excel里有些人喜欢在单元格里加换行符、Tab字符，甚至全角空格，这些字符导进达梦后看起来没什么，但实际做字符串匹配或者数据清洗时会出问题。建议导入前先做数据清洗，把控制字符替换掉，特别是手机号、身份证号这种关键字段。

4.2 Oracle导入遇到的字符集和类型问题

Oracle是字符集最敏感的数据库，没有之一。导入中文乱码是最常见的问题，根因通常是源文件字符集和目标库字符集不匹配。

快速排查方法：导入后随便查一条记录，看中文是否正常。如果乱码，先查目标库的字符集，用SQL：SELECT USERENV('LANGUAGE') FROM DUAL。如果结果是SIMPLIFIED CHINESE_CHINA.AL32UTF8，说明库是UTF8编码，那源CSV文件必须用UTF8编码保存。如果库是ZHS16GBK，CSV文件就要存成ANSI/GBK编码再导。SQLark在导入时也能指定文件编码，你只要选对就行。

另一个Oracle特有的问题是数字格式。Excel里如果单元格数字带千分位逗号，比如"1,234,567"，导入时会被当成字符串或直接报错。处理办法：在Excel里先把这些列格式化为纯数字，不带千分位，或者用文本编辑器处理后再导。

还有一种情况：ORA-12899，值太大。这是因为目标表字段长度不足。比如手机号字段建成了VARCHAR2(11)，但Excel里有些号码前带了"0"或者包含空格，变成了12位，导入就报值太大。解决办法是导之前先看错误日志，把字段长度统一加大，或者先在Excel里把数据格式处理干净。

4.3 MySQL和PG的导入注意点

MySQL这边，最常见的坑是自增主键冲突。如果目标表有AUTO_INCREMENT主键，而Excel数据里也带了ID列，导入时可能出现主键重复的报错。解决方法是导入时跳过ID列，让数据库自己生成自增ID；或者把自增起始值调大，避免和已有数据冲突。另一个容易忽略的是SQL mode，有些MySQL实例开启了STRICT_TRANS_TABLES，导致导入时稍微越界的数值直接被拒绝，这时候需要先检查SQL mode再做调整。

PG这边，最让人头疼的是"整数类型与字符串比较"这类严格类型检查。PG不像MySQL那么宽松，Excel里"00123"这种文本格式的数字，导入到INTEGER字段时会报错。同理，日期时间字段对格式的要求也更严格，建议在导入前把Excel里的日期统一转换成标准格式，比如"2024-01-15 10:30:00"，省得导进去一堆非法格式错误。PG还有个特点：事务回滚能力很强，意味着你导入一个大事务如果中间出错，可能整个事务全部回滚，一个数据都没进去。这种情况容易让人误以为"没报错就成功了"，实际上数据量为0。所以导大表前，一定要先看SQLark日志里的提交记录，确认确实提交成功。

4.4 问题排查速查表

我整理了一张速查表，基本都是实际工作中碰到的，按优先级从高到低排。

排查时有一个通用原则：不要只看错误信息，要打开错误日志逐行看。SQLark的错误日志会告诉你是哪一行、哪个字段、为什么失败，信息量非常大。很多你以为的疑难杂症，其实在日志里已经写得清清楚楚。

5. 让导入更快更稳的实战技巧

5.1 大数据量导入的性能调优

导入千万级数据时，直接默认配置跑，大概率慢到你怀疑人生。分享一下我调优的几个方向。

第一，尽量用文件导入而不是SQL执行。同样的一批数据，SQLark走ODBC或批量装载路径时，内部会尽量用数据库原生的批量插入接口，比一条条INSERT快太多了。能选文件导入就直接选文件导入，不要多此一举转成SQL脚本再执行。

第二，批次大小要调，但别过分调大。达梦和Oracle在批量提交时能明显感觉到性能提升，但批次太大会导致回滚段或UNDO压力过大。我按经验值来看，常规服务器配置下，单批2000到5000条是比较稳的区间。具体可以看导入时的每秒行数输出，如果导入速率越来越慢，说明批次可能设置得太大，系统在承受压力。

第三，导入前能删的约束先删掉。特别是外键约束和唯一索引，在导入大量数据时，数据库每插入一条都要做一次约束检查，开销很大。我会在导入前禁用或删除约束，导完再重建。注意，生产环境这么干之前必须走变更流程，别让业务系统裸奔着。

第四，若目标表是Oracle，考虑临时把表改成NOLOGGING模式，导完再改回LOGGING。NOLOGGING模式减小redo日志的生成量，对导入性能提升非常明显，代价是如果在导入过程中数据库崩溃，这个表的数据可能需要重建。测试环境随便用，生产环境谨慎点。

5.2 数据校验：导入完成不等于万事大吉

导入完成提示"成功"，不代表数据一定对。我每次导完数据，至少要做三层校验。

第一层是数量校验。源文件多少行，目标表多少行，对一下数字。如果不一致，去错误日志里找原因。这一步最简单，也最容易做。

第二层是抽样校验。随机查几条数据，跟源文件里的原始记录比对，重点看日期时间、金额、手机号这几类格式敏感的字段。比如日期差了8个小时，很可能是时区问题；金额少了几毛钱，很可能是浮点精度问题。

第三层是业务校验。如果你知道这张表的数据有什么业务含义，就写几个统计SQL验证一下。比如导入的是订单表，那就按天统计一下订单数量，看看趋势是否合理。如果某一天的订单量突然飙升到异常水平，很可能就是导入时出现了重复数据。

校验这步千万别省。我见过太多人导完数据就直接交付，结果业务方跑出来的报表对不上，最后查出来是导入时有一批数据的主键被自动改写了，白费了一整个周末去返工。

5.3 让SQLark更好用的几个小设置

最后分享一些让日常操作更顺手的小技巧。

连接管理那边，可以给每个连接分类打标签。SQLark支持给连接设置颜色标志，我把生产环境标红、测试环境标蓝，一眼就能分辨，免得连错库。

查询历史默认会保存，但我建议定期清理一下，尤其是包含敏感数据的查询。有些公司对数据库访问审计要求严格，保存大量查询历史可能带来合规风险。另外，SQLark支持把常用的导入配置存成模板，如果你每周都要重复导入相同格式的Excel，可以把字段映射、批次大小、文件编码这些配置保存下来，下次导入直接选模板，连映射都不用重新设置。

快捷键方面，执行SQL用F5（或者自定义），格式化SQL用Ctrl+Shift+F，这些能记住就记住，效率提升是实打实的。刚开始用可能不习惯，坚持两周就顺手了。

6. 实操中我沉淀下来的几点经验

把SQLark作为主力工具用了大半年，导入数据保守估计也有几百次了，几点感受分享给你。

第一，不要迷信"一键导入"。任何工具的自动映射都存在局限性，尤其当源文件格式混乱时，宁可多花两分钟在字段映射界面确认一遍，也不要图快直接点下一步。一个字段映射错了，导完发现问题再回头清理，成本远高于前期检查。

第二，导入前备份目标表数据，是个被低估的好习惯。特别是往生产环境的表里导入数据，先跑一条创建备份表的SQL：CREATE TABLE T_USER_BAK_20240115 AS SELECT * FROM T_USER。如果导入出问题，可以直接从备份表恢复，省一条后路。

第三，多了解不同数据库的底层差异，能帮你少踩很多坑。SQLark的适配做得再好，也必须在数据库本身的约束范围内工作。达梦和Oracle在事务模型上比较接近，走批量提交效果更明显；PG的MVCC机制决定了它在同一时刻的写冲突处理方式和MySQL不太一样，导数据时尽量避开业务高峰，减少锁冲突。

工具是辅助，理解才是根本。SQLark帮我统一了操作的入口，但真正让导入又快又稳的，是我对每类数据库特性的理解和实操中的经验沉淀。如果你是刚接触这类工作，建议从一个小数据集开始，完完整整走一遍导入流程，搞清楚每一步在做什么、为什么这么做，再上大数据量。这样遇到问题的时候，你至少知道去哪里排查，而不是慌慌张张地问人。

个人体会就一句话：数据导入这件事，看着简单，做好不容易。了解你的数据、了解你的数据库、再用好你手头的工具，三样都不能少。希望这篇实战记录能帮你少走点弯路。