跨库数据迁移与导入导出：FlySpeed数据库工具实战解析

1. 先放下它的架子：FlySpeed不是一个“又一个Navicat”，而是藏在你工具箱角落的数据库瑞士军刀

做数据相关工作的人电脑里，多半不止装一个数据库客户端。SQL Server Management Studio管MSSQL，Navicat管MySQL，DBeaver管PostgreSQL，Oracle得再装一个SQL Developer，加起来小十个工具，每个都要配连接、记密码、等启动。我过去很长一段时间就是这么过来的，直到有一次要给几十张表做跨库迁移，在三个客户端之间来回切，才被同事安利了FlySpeed。

FlySpeed，全称应该是FlySpeed Data Wizard，严格意义上它不算是“客户端”那一挂的。它的定位更偏向“查询工具+数据搬运工”：既能当普通SQL查询工具用，连接SQL Server、Oracle、MySQL、PostgreSQL、SQLite、Access这些常见库，又内置了一套很强悍的数据导入导出和数据迁移引擎。翻译成人话就是——同一套界面里，你既能写SQL查数据，又能把一张表、一个查询结果，几秒钟倒腾成Excel、CSV、JSON、XML，甚至直接灌进另一个数据库。

这篇文章我就从实际使用角度聊聊它，包括日常查询怎么用、数据导入导出怎么配置、和主流工具对比下来各自的边界在哪、以及我用FlySpeed这两年踩过的坑和总结出的经验。

2. FlySpeed的日常干活路径：从连库到拿到干净结果集

FlySpeed用起来其实没有太多学习门槛。界面上左边是数据库连接树，右边是标签页，下面有输出面板，这套布局在数据库工具里几乎算是标准配置了。不过它在细节上花的心思不少，值得摊开讲。

2.1 新建连接：选驱动、填主机、测试连通性

第一步自然是建连接。FlySpeed支持左右两边各建一个连接，这样你可以一边连着源库，一边连着目标库，两边对照操作，后续做数据迁移的时候非常方便。

新建连接的对话框里需要选数据库类型。这里有个隐藏选择：同一种数据库，它可能同时提供“原生驱动”和“ODBC驱动”两个选项。比如连SQL Server，用原生驱动的时候，需要填主机名、端口、实例名、用户名、密码；用ODBC驱动则是在你本地已安装ODBC数据源的基础上做选择。

我的建议是优先用原生驱动。原因有三个：

• 原生驱动的网络协议层是厂商自行实现的，解析效率通常比经过ODBC管理器转一层要高，跑大结果集的时候更明显。
• ODBC驱动有时候会受本地驱动版本影响，比如链接服务器、特定数据类型的兼容性都和本地ODBC驱动关系很大，换个电脑可能表现就不一样。
• FlySpeed原生驱动对常见类型的支持更全，比如SQL Server的uniqueidentifier、Oracle的CLOB，映射到目标格式时不容易出幺蛾子。

当然，遇到没有原生驱动的数据库，ODBC就是兜底方案。实测连一些老旧的Access、FoxPro库，ODBC几乎是唯一选择，这种情况不要硬撑，该用ODBC就用。

连接串的细节也可以存下来。FlySpeed支持把某个连接保存成配置文件，下次启动直接加载。我一般会建三个连接配置：开发库、测试库、生产库，用名字区分，避免连错。

2.2 查询编辑器：写SQL、看执行计划、格式化语句

连接好之后就能开查询了。查询编辑器自带语法高亮、代码补全、括号匹配，这些在2025年已经不算什么亮点，但它有几个细节是实际用起来才觉得“这工具是真的被拿来做事的”：

第一个是结果集和编辑器在同一窗口内分区显示，不需要开新标签页。查出来的数据集默认显示在编辑器下方，你可以直接在网格里继续筛选、排序、复制行、编辑单元格，不用再SELECT *套一层子查询。

第二个是执行计划的入口非常浅。大多数工具里看执行计划要另开窗口或单独面板，FlySpeed是直接在工具栏点一下，把执行计划展示成图形化树。对于排查慢SQL来说，少一步操作就很关键。

第三个是SQL格式化排版。这个功能虽然Navicat也有，但FlySpeed的格式化规则可以自定义，比如关键字大写还是小写、子查询缩进几个空格、JOIN条件怎么对齐。我习惯关键字大写、表名字段名保持原样，格式化完的语句直接贴上生产环境的代码评审，省一道工序。

顺便说一句，提到慢SQL优化，就不得不提为什么“去重查询”是一个高频场景。比如：

sql复制SELECT DISTINCT department_id, job_title
FROM employees
ORDER BY department_id;

这段SQL在任何工具里都能跑，但FlySpeed的网格结果集可以直接对视图中已经查出来的行做二次过滤和去重对比，不需要反复改SQL。如果带DISTINCT的结果特别大，还能在结果集面板里按列分组统计，比单纯用眼睛扫网格靠谱得多。

2.3 结果集会话：像Excel一样编辑查询结果

说到结果集，这是FlySpeed一个让我用起来最舒服的地方。很多SQL工具的查询结果是只读的，想改数据得再走一遍UPDATE语句。FlySpeed则允许你在结果网格上直接编辑单元格，改完以后它可以把你改过的行生成一条更新语句，执行回库里。

听起来像“黑科技”，其实它原理不复杂：FlySpeed在执行查询的时候会记住每一行对应的主键或行标识，用户改了网格里的某个值，它基于这个行标识生成对应的UPDATE语句。所以它要求查询结果里包含主键或唯一索引，否则就没法精确回写。了解了这层原理，你也能理解为什么有些查询能编辑，有些不能——通常是因为SELECT里没带主键字段。

结果集面板还支持对列做分类汇总。选中一列，右键就能看到合计、均值、最大值、最小值、计数等聚合功能，不用写GROUP BY。这和Excel里选中区域看状态栏统计有点相似，但FlySpeed的粒度是“列级别”，且可以复制成格式化文本，直接贴进报表里。

这个功能在做数据核查的时候特别有用。比如审计一批订单数据，我一般先跑一条查询捞全量，然后在结果网格里对金额列右键看总和，和业务系统对账数字核对，不一致再下钻查月份、查区域，整个排查链路流畅很多。

3. 数据搬运是FlySpeed最被低估的能力

说实话，如果只是写SQL查数据，FlySpeed很难说是“不可替代”的，毕竟能查SQL的工具一大把。但它真正的重头戏是数据搬运——数据库到数据库、文件到数据库、数据库到文件，这三条链路它几乎都做到了“开箱即用”的程度。

3.1 数据库到数据库：跨库导数据的核心玩法

我最常用的场景是把SQL Server的数据整表搬到MySQL。这种活很多人第一反应是装一个迁移工具，或者用ETL平台。但FlySpeed提供了更轻量的方式：在左侧连接源库，右侧连接目标库，然后在源库表上右键选择“数据传输”，跟着向导走。

向导里可以选择复制表结构、只复制数据、还是仅复制结构。目标表不存在时，FlySpeed会基于源表的字段类型帮你生成建表语句。当然类型映射不可能100%完美，比如SQL Server的datetime2到MySQL的datetime(3)，精度可能会丢一位；SQL Server的nvarchar(max)到MySQL的longtext一般没问题，但如果你映射成varchar(255)，超长内容就会被截断。

所以我的建议是：类型映射向导出来的结果只能当草稿，最终以你自己核对的字段清单为准。特别是主键、自增列、默认值这三类，自己动手确认一次，比事后找数据差异要划算得多。

如果数据量很大，比如几百万行甚至上亿行，FlySpeed支持分批提取，可以设置每次取5000行或10000行，边读边写，不至于一次性撑爆内存。批大小不是越大越好，实测下来默认值附近（5000-10000）是最稳的区间，设太大容易触发目标数据库锁等待或内存压力，设太小吞吐量又上不来。

这里再提一个很实用的场景——跨库数据同步。假设业务数据在SQL Server，分析库在PostgreSQL，每次同步只同步最近一天的数据，可以这样写源查询：

sql复制SELECT * FROM orders
WHERE order_date >= DATEADD(day, -1, CAST(GETDATE() AS date));

然后用FlySpeed的数据传输向导指定“使用查询作为数据源”，把这段SQL作为抽取逻辑，目标端选择PostgreSQL的orders表。相当于用查询串代替整表复制，配合FlySpeed的定时任务功能，就能做到轻量级的增量同步。

3.2 文件到数据库：CSV、Excel、JSON的编码与类型陷阱

再来说说文件导入。运营同学给我一个Excel文件，里面有几十万行活动报名数据，要导进MySQL，这是每周都要发生的事情。

FlySpeed对Excel文件的支持相对省心，xlsx格式可以直接读，不会像老工具那样要求先转成CSV。但CSV导入就有一个经典大坑：编码。

Windows平台导出的CSV文件，很多是ANSI编码，也就是GBK；而MySQL一般默认UTF-8。如果你拿到一个GBK编码的CSV直接导入UTF-8的数据库表，中文大概率变乱码。FlySpeed在CSV导入向导里可以手动指定文件编码和分隔符，中文环境下建议选择GB18030或GBK作为输入编码，目标端按UTF-8处理。

另一个坑是Excel里的“假数字”。比如某个证件号码列本来是文本格式，但在Excel视图中显示成科学计数法1.23E+17，导入后如果目标字段是varchar，你会惊讶地发现数据变成了“123000000000000000”，精度丢得一塌糊涂。这种情况下，建议先从Excel工具里把该列设置成文本格式再导出，或者导入后在FlySpeed里把目标列临时改成varchar，等导入完成再转换一次。

JSON文件导入也同样常见。FlySpeed支持把JSON数组里的每个对象映射成一个目标行，字段映射以JSON的键名为主。如果JSON是嵌套结构，它有展平功能，可以把嵌套字段展开成类似a.b.c的列名。但嵌套特别深的JSON，还是建议先用脚本预处理一下，FlySpeed的展平能力毕竟不是专门的JSON解析器。

3.3 数据库到文件：导出模板、定时任务与增量备份

导出方向同样实用。FlySpeed可以把查询结果导出为Excel、CSV、XML、HTML、JSON、SQL文件等格式。导出生成的文件如果是要给非技术同事看的，Excel格式最合适；如果要给下游程序对接，JSON或CSV优先。

这个环节有个功能我很喜欢：保存导出模板。每次导出时，可以选择列顺序、列名、是否带表头、日期格式、数字格式，这些配置可以保存成一个模板，下次导出同一个报表直接选模板，参数全部记住，不用再一项项调整。

举个例子：每周给业务发一份订单明细Excel，列顺序固定是订单号、客户名、商品、数量、金额、下单时间，金额保留两位小数，日期格式是yyyy-MM-dd HH:mm:ss。我配置好模板之后再导出，全程点三下鼠标就生成文件了。

结合定时任务，还能做到更多。FlySpeed内置了任务计划功能，可以定时执行查询并导出文件。我用它做过一次简单但管用的日报表自动化：每天早上8点自动从数据库导出前一天的数据，生成SQL文件和CSV放到指定目录，再通过企业的定时发送脚本把文件发到群机器人。整个链路里FlySpeed只负责数据导出，但它是这条流水线里最关键的一环。

前端时间有网友问“*.sql文件如何打开”，其实这得分场景：如果是一个数据库的完整导出脚本，用任意SQL工具执行即可；如果只是某段SQL片段，直接用文本编辑器看也行。FlySpeed里就能直接打开SQL脚本文件并执行整个文件，批量跑历史补数脚本时比逐段复制粘贴高效很多。

4. 和主流的SQL工具对比：FlySpeed的取舍边界

每个工具都有它的适用范围，FlySpeed也不例外。经常有人问我和DBeaver、Navicat、HeidiSQL这些工具比，该选哪个。我直接用一个表格来说清楚各自的侧重点。

从上表能看出来，FlySpeed最突出的点是“跨库数据存取”，它不像DBeaver那样什么都支持但每个都点到为止，而是把导入导出和数据迁移做成了主菜。如果一个场景的诉求是“把数据快速搬过去”，FlySpeed通常比另外几个工具都顺手。

4.1 哪些场景FlySpeed明显更顺手

排第一的非“跨库搬数据”莫属。横向对比时你会发现，DBeaver的导出向导选项很多，但默认行为经常要自己调；Navicat导数据要新建传输任务，步骤相对重；FlySpeed则把“源连接-查询/表-目标连接-表”这个路径做到极短，三步五步行云流水。

排第二的是文件格式转换。比如从SQL Server导一个JSON给开发，再从开发给的CSV灌回Oracle，这种反复横跳，FlySpeed内置格式支持非常充分。你可以在一个界面里完成读数据库-转换格式-写文件，不需要借用Excel做中间人。

排第三的是结果集的正向编辑。能直接改查询结果并回写数据库，这一点在写一次性数据订正脚本时非常节省时间。虽然Navicat也有类似功能，但FlySpeed对“无主键结果集”的处理更明确——它会直接告诉你为什么不能编辑，并引导你调整查询语句。

4.2 哪些场景不要用FlySpeed

FlySpeed不适合做复杂的数据库建模工作。虽然它能看表结构、建表，但ER图设计、关系反推、可视化管理这方面，还是DBeaver或专业的建模工具更擅长。

FlySpeed也不适合做重度开发调试。如果你需要在IDE里调试存储过程、做代码版本管理、跑单元测试，DataGrip这类集成开发工具更合适。FlySpeed的强项始终是取数、查数和搬数，而不是软件工程化的数据库开发。

还有一点要提醒：FlySpeed的UI风格比较传统，布局信息密度高，新手第一次打开可能觉得界面有点“老气”。但用习惯以后你会发现，这种高密度布局的好处是操作路径短，所有功能都在一屏之内，不用频繁翻菜单。

4.3 怎么根据自己的场景选型

我给这类问题的标准回答是：先想清楚你的主要任务是什么。如果你一个月里有三分之一时间在做跨库导数据、转格式、导报表，那么FlySpeed这类以数据搬运为核心的工具值得认真考虑；如果你主要是连一个库写业务代码、看数据结构，DBeaver和DataGrip更合适；如果你是运维，日常就是备份恢复加查慢日志，Navicat或原厂工具往往更顺。

工具选择没有绝对的标准答案，只有适不适合。至少在我这里，FlySpeed和DBeaver是并存的：DBeaver用来“看数据库长什么样”，FlySpeed用来“把数据库里的数据弄到需要的地方去”。

5. 用了两年FlySpeed，我踩过的坑和总结的几条经验

工具看文档是一回事，真正用了两年，很多坑只有实际跑一遍才会发现。这一节我集中写几条自己的经验，不一定每条都适合所有人，但应该能帮你少走一些弯路。

5.1 导出CSV给下游程序时，多做一个编码选择动作

第一个坑是CSV编码。我之前做过一次数据对接，FlySpeed导出的CSV文件，下游Java程序读出来全是乱码，排查半天发现是编码问题。FlySpeed导出CSV时默认可能是按操作系统本地编码导出，而下游程序是按UTF-8读取的。

解决办法很简单：在导出向导里把文件编码显式改成UTF-8，或者让下游用什么编码，你就导什么编码。重点是要“显式设置”，不要依赖工具默认。类似的，导入CSV时也建议先明确源文件的编码，再导入，不要用“自动检测”，因为自动检测偶尔会猜错。

5.2 大批量导入时，批次参数和错误处理要配合调

前面提到过传输向导的批大小设置。这个参数直接影响导入速度。我一开始图省事，直接用默认值，结果导一张300万行的表导了将近一个小时。后来把批大小调大，只花二十分钟左右就完成了。

但这并不意味着批大小越大越好。批大小太大，目标库的事务日志会比较紧张，如果中途出错，回滚的开销会比较大。建议针对你的目标库情况做一两次小规模测试，找到合适的批次大小。比如MySQL的InnoDB引擎，单次事务处理1万行以内通常比较轻松；Oracle的话，事务能力强很多，可以考虑调大。

错误处理策略也要提前选好。FlySpeed在导入时通常可以设置“遇到错误是中止还是继续”。大量脏数据混在业务数据里很常见，如果数据里有若干行类型不对、长度超限、违反约束，你不想整个导入失败。这时候选择“跳过错误行并继续”，等导入完成再把错误日志捞出来人工处理。

5.3 免费版和商业版的边界，用之前一定看清楚

FlySpeed有免费版（Express版）和商业版之分。免费版能完成日常查询、单表导入导出，但对于定时任务、复杂数据转换、大数据量迁移这种高级功能，通常会被限制。我建议你在用之前去官网读一下版本对比，别等到自动化任务跑不了才着急。

如果你只是个人查询数据，免费版完全够用；如果要做企业级的定时同步、数据仓库抽取，商业版是合理的投入。很多工具软件的价值不仅在于功能本身，还在于它能把你从重复劳动里解放出来。

5.4 配合慢SQL排查的一个实测经验

最后分享一个FlySpeed在慢SQL排查里的实际用法。之前有个业务系统某条查询响应特别慢，初步怀疑是WHERE条件里的BETWEEN AND用法没走索引，但不确定。我在FlySpeed里连上生产库（只读账号），把SQL粘到查询编辑器，打开执行计划一看，果然在日期范围过滤上走了全表扫描，没有走索引。

然后我把语句改成两个边界条件的联合写法再测一次：

sql复制SELECT *
FROM orders
WHERE order_date >= '2024-01-01'
  AND order_date < '2025-01-01';

这次执行计划里就命中了索引。后来进一步确认是函数包了一层日期字段，导致索引失效。整条排查链路里，FlySpeed的图形化执行计划和结果集对比给了我很大帮助——因为改完SQL以后，我直接在一个界面里并排跑了两次查询，肉眼对比了返回行数和耗时，不需要在两个工具之间来回切换。

像这样的情况，你需要的不是功能最全的工具，而是能把“写SQL-看计划-对比结果”这条链路做到最短的工具。FlySpeed在这点上确实做到了。

回到开头那个问题：为什么用了那么多数据库客户端，我还在用FlySpeed？答案很简单——它解决的是其他工具不太重视的“数据到达目的地”的问题。查数据谁都会，但把数据变成可交付的文件，把数据原封不动地搬到另一个库，还能批量、定时、自动化，这才是FlySpeed真正的价值所在。如果你也经常干跨库导数据、手工导报表这些活，我建议你把它装上一试，大概率会节省大量时间。