🧰 会计人的第一个数据库工具：20MB 的 DBX，能把 Excel 直接倒进库里

不用装 Java，不用先把表格另存为 CSV，不用背 SQL 语法。 一个二十来 MB 的开源小工具，可能是财务部门最容易被忽略的效率升级。

一、先说个会计人都遇到过的场景

月底，你手里有一份 Excel 工作簿：三个 sheet，分别是销售发票明细（发票号、客户编码、开票日期、金额、税额）、银行回款流水（对方户名、对方账号、到账日期、金额）、应收账款台账（客户编码、客户名称、期初余额）。发票四万多行，流水三万多行。

领导要的是一份账龄分析表：哪些款超期了、超了多久、哪些发票至今没有对应的回款、哪些回款找不到对应发票。

这是一道典型的三表关联题——发票和台账靠"客户编码"连，发票和流水靠"客户名称↔对方户名 + 金额 + 日期"核销。逻辑不复杂，但 Excel 撑不住这个量级：VLOOKUP 一拉就转圈，多条件核销得嵌套 MATCH + INDEX 再套 SUMIFS，一个公式改一次全表重算半分钟，而且一对多的部分回款根本处理不了——一笔发票分三次到账，VLOOKUP 只会返回第一条。

你知道该上数据库，写几句 SQL 做 JOIN 就完事了。于是你找了个工具，然后卡在了第一步：

它不接受 .xlsx，只接受 .csv。

于是你开始了一轮熟悉的折腾：

• 一个工作簿三个 sheet，CSV 一次只能存一个，你得另存三次；
• 存完打开一看，18 位的纳税人识别号变成了 9.13101E+17，后三位全是 0；
• 科目代码 001 变成了 1，前导零没了；
• 导进去中文全是乱码，因为 Excel 在中文版 Windows 上默认存的是 ANSI/GBK，而库里等着的是 UTF-8；
• 凭证日期被重写成了本地格式，(1,234.00) 这种会计习惯的负数写法直接解析失败；
• 公式、批注、单元格格式，一个都不剩。

等 CSV 终于伺候好了，一个小时过去了。数据还没开始算。

问题不在你，在工具的设计前提上——它是给开发者写的，开发者手里的数据本来就是 CSV。

二、DBX 是什么

DBX 是一款开源、免费、跨平台的轻量级数据库管理工具和 SQL 编辑器，代码托管在 GitHub（github.com/t8y2/dbx），官网是 dbxio.com。

技术上是 Tauri 2 + Rust + Vue 3 的组合，说人话就是三个特点：

它支持的数据库覆盖了财务场景里几乎会遇到的全部类型：MySQL、SQL Server、Oracle、PostgreSQL、SQLite、DuckDB、ClickHouse，以及达梦、人大金仓、openGauss、OceanBase、GaussDB 等国产信创数据库。官方口径里总数随版本从 40+ 到 100+ 不等，但对会计人来说，关键是"你司财务软件后台那个库，它大概率连得上"——不少财务系统的后台库就是 SQL Server 或 Oracle。

三、核心差异：Excel 直接导入，而不是先转 CSV

这是最值得会计人留意的一点。

DBX 原生支持直接导入 .xlsx、.xlsm、.xls 文件，并且可以在导入时选择工作表。

而 DBeaver（目前最主流的免费数据库工具）的社区版，导入 Excel 的标准路径是：先在 Excel 里另存为 CSV，再用导入向导读 CSV。

差别不只是少点两下鼠标。看下面这个对照：

3.1 多工作表

• DBeaver 路线：CSV 是纯文本格式，一个文件只能承载一个 sheet。三个 sheet = 另存三次 + 导入三次 + 建三张表。
• DBX：选择"创建新表"时可以一次选多个文件，Excel 文件会按工作表自动拆成独立任务，每个 sheet 各自生成建议表名、各自预览、各自映射、各自执行。一个工作簿扔进去，三张表一起建好。

3.2 中文乱码

• DBeaver 路线：转 CSV 时编码就已经定了。选错就是满屏 锟斤拷，回去重存。
• DBX：导入向导里编码是可选项，支持自动检测、UTF-8、GBK、UTF-16 LE/BE，检测到不对可以当场换编码重新预览，不用回去动源文件。

3.3 数据被 Excel “改写”

这是 CSV 路线最隐蔽的伤害：另存为 CSV 的那一刻，Excel 会按它自己的理解重写数据。长数字变科学计数法、前导零丢失、日期本地化、公式变计算结果——你导进去的已经不是原始数据了，而且很难发现。

DBX 直接读 .xlsx，绕开了这一层有损转换。

3.4 导入前的确认环节

DBX 的导入不是"选中文件就写库"，而是一个五步向导：

1. 选文件和目标方式 —— 导入已有表，还是根据文件新建表
2. 调整解析选项 —— 编码、标题行在第几行、数据从第几行开始、到第几行结束、选哪个工作表、空字符串是否按 NULL 处理、是否去除首尾空格
3. 检查字段映射 —— 源字段对目标字段，右侧有实际数据预览可以核对
4. 复核执行计划 —— 目标连接、库、Schema、表名、导入模式、预计行数、批大小，全部摊开给你看
5. 执行并检查结果 —— 进度、已导入行数、耗时、错误明细

第 2 步里的"标题行 / 数据起始行“对会计人特别实用。业务部门发来的表，前三行往往是"XX公司2026年8月销售发票明细表 / 编制人：张三 / 单位：元”，真正的表头在第四行。DBX 可以直接指定从第几行开始读，你不用先删掉那几行再另存一份。

第 4 步的价值在于：它让"我要往哪张表写多少行"这件事在真正动手前变成一份可以核对的清单。 财务数据写错了不好收拾，多一道复核不亏。

3.5 建表不用会 SQL

选择"创建新表"时，DBX 会根据预览数据自动推断字段类型，你可以在执行前修改表名、字段名和类型。

也就是说，你不需要先写 CREATE TABLE，不需要知道 DECIMAL(18,2) 和 VARCHAR(50) 的区别在哪，就能把一张 Excel 台账变成一个真正的数据库表。

提醒一句：官方文档明确说明，类型建议只是起点，日期、金额精度、长文本这几类字段建议在执行前人工确认一遍。金额字段务必检查是不是 DECIMAL 而不是浮点类型——这一点上别偷懒。

四、DBX 与 DBeaver 逐项对比

需要如实说明的两点

第一，DBeaver 的付费版本（PRO / Enterprise）是可以直接读 Excel 的。 它提供了文件驱动，能把 Excel、CSV、JSON、XML、Parquet 当作数据库表直接查询。所以严格讲，“不能直接导 Excel"是社区免费版的限制，不是 DBeaver 整个产品的限制。但财务部门要走采购流程买一个数据库客户端，通常比让工具适配现有流程难得多。

第二，DBeaver 依然是极其优秀的工具。 它的功能深度、数据库覆盖面、生态成熟度都是行业标杆，很多复杂场景下它仍然是更好的选择。本文的比较只针对一件事：一个会计人，想把手里的 Excel 快速变成可查询的数据库表，哪个更省事。 在这个具体问题上，DBX 的答案明显更短。

补充一个可能影响判断的细节：有资料提到 DBeaver 自 24.3 版本起，将 Excel 读写能力拆分为可选插件，社区版需手动安装，且部分后续版本存在安装后仍不可用的情况。这条信息建议以你所用版本的实际表现为准，本文不作为定论。

五、除了 Excel 导入，DBX 还有哪些点戳会计人

5.1 不会写 SQL？内置 AI 助手可以用中文提需求

这可能是对会计人最有价值的功能。DBX 内置 AI SQL 助手，可以直接输入自然语言：

“把发票明细表和回款流水按客户编码和金额关联，找出开票超过 90 天仍未收到对应回款的发票，按客户汇总欠款金额，从大到小排列”

它读取当前库表结构作为上下文，生成对应 SQL。另外还支持选中一段看不懂的 SQL 让它用大白话解释，以及给出慢查询优化建议。

上面这句话，正是开头那个账龄分析需求。你不用记 JOIN 怎么写、不用管日期相减该用 DATEDIFF 还是 DATE_SUB，用中文说清楚业务需求，SQL 交给它。

对财务人的实际意义是：你不需要系统学 SQL，就能把取数需求自己实现，不用每次都排 IT 的队。

使用前请确认公司数据安全政策。AI 助手需要配置模型服务，涉及财务数据的库，建议先确认是否允许接入外部模型，或使用本地部署的模型。

5.2 改数据之前，先给你看要执行什么 SQL

DBX 的数据表格可以直接在单元格里编辑，但修改不会立刻写库，而是先把准备执行的 SQL 展示出来，你确认之后才保存。

这个设计对财务场景非常重要。误改一张凭证表的后果，谁都清楚。多一道"你确定要执行这条 UPDATE 吗"的确认，值。

此外它还提供只读保护和生产环境保护，可以给连接加上限制，避免手滑。

5.3 十几万行明细账，不卡

查询结果用的是虚拟滚动，几十万行数据表格也不会把界面拖死。翻凭证明细、拉银行流水的时候，体感差别很明显。

5.4 查询结果一键导出成 Excel

反过来也通：从库里查出来的数据，可以直接导出为 Excel、CSV、JSON、Markdown，甚至 INSERT 语句。

审计要底稿？导 Excel。要给领导看数据？导 Excel，不用教他怎么连库。要复现一个问题到测试库？导 INSERT 语句。

5.5 财务部的电脑，装得下也跑得动

这一条容易被忽略，但很现实：

• 财务部门的电脑通常不是高配，上面还跑着财务软件、税务客户端、网银控件、Office；
• 很多公司的员工电脑没有本地管理员权限，装不了需要配置 Java 环境变量的软件；
• IT 部门对一个"要装 JRE、占 1GB 内存、还要开放数据库端口"的申请，审批会谨慎得多。

一个 20MB、无需运行环境、双击即装的绿色小工具，通过内部审批和 IT 白名单的难度，明显低一个量级。

5.6 免费，不用走采购

Navicat 一年授权几百到上千，DataGrip 订阅更贵，DBeaver PRO 也要钱。财务软件采购流程之长，做过预算的都懂。

DBX 开源免费，没有功能限制、没有试用期、没有付费解锁。对个人学习和部门内部试点来说，试错成本接近零。

5.7 信创环境也覆盖

如果单位在用达梦、人大金仓、openGauss、GaussDB 这类国产数据库（国企、事业单位、金融机构 increasingly 常见），DBX 原生支持，不需要额外找专用客户端。

5.8 团队可以共用一套配置

DBX 提供 Docker 自托管版本，部署在服务器上，团队成员用浏览器访问，桌面端和网页端体验一致。

对财务共享中心、多主体核算团队来说，这意味着连接配置可以统一管理，不用每个人在自己电脑上配一遍数据库连接。

六、实操：把开头那三张 Excel 表，变成能关联查询的数据库

下面用第一节的应收账款场景走一遍全流程。你照着做，最后能拿到领导要的那张账龄分析表。

6.1 三张表的字段假设

为了让 SQL 能直接抄，先约定好表名和字段名（你实际导入时，DBX 会按 Excel 表头自动命名，可以在这一步改成下面的样子，方便对照）：

invoices（销售发票明细）

bank_receipts（银行回款流水）

ar_ledger（应收账款台账）

两个必须注意的类型问题：

• tax_no、payer_account、customer_code 一定要设成文本类型，不能是数字。18 位纳税人识别号超出整型范围，账号的前导零也会丢——这正是第三节说的 CSV 路线最容易踩的坑。
• 金额字段用 DECIMAL，别用浮点类型（FLOAT/DOUBLE/REAL）。浮点数存 0.1 + 0.2 不等于 0.3，金额上加总会出现分位误差。
• 补充一句：如果你用 SQLite 练手，它没有严格的 DECIMAL 类型，会按数值亲和性存储。做金额汇总时套一层 ROUND(..., 2) 就够用了；但如果是要上生产的数据，建议用 MySQL、SQL Server 或 PostgreSQL，它们对 DECIMAL 有真正的精度保证。

6.2 导入的八个步骤

1. 到官网 dbxio.com 或 GitHub github.com/t8y2/dbx 下载对应系统的安装包，双击安装；
2. 新建连接。本地练习选 SQLite 最省事——文件型数据库，不用装服务端，指定一个文件路径就能用；
3. 在连接上右键 → 导入 → 选择”创建新表"；
4. 选中 .xlsx 文件。三个 sheet 可以一次全选，DBX 会自动按工作表拆成三个独立任务，每个任务单独预览、单独映射、单独执行；
5. 调整解析选项：标题行在第几行、数据从第几行开始、编码是否正确、空单元格是否按 NULL 处理；
6. 核对字段映射和自动推断的类型，按上面 6.1 的表格逐个检查金额、日期、编号三类字段；
7. 复核执行计划里的表名和预计行数，确认后执行；
8. 看进度页的已导入行数和错误明细，与 Excel 里的记录数对一下——这一步别省，对平了才算完成。

6.3 导完先做两步体检

数据进了库不等于数据是对的。开算之前，先跑这两句。

体检一：行数对不对

SELECT 'invoices'     AS 表名, COUNT(*) AS 行数 FROM invoices
UNION ALL
SELECT 'bank_receipts',        COUNT(*)          FROM bank_receipts
UNION ALL
SELECT 'ar_ledger',            COUNT(*)          FROM ar_ledger;

三个数字要跟 Excel 里的记录数完全一致。差一行都要回去查——通常是有空行被当成数据，或者标题行设错了位置。

体检二：编号精度有没有丢

SELECT customer_name, tax_no, LENGTH(tax_no) AS 位数
FROM ar_ledger
WHERE LENGTH(tax_no) <> 18;

这句查出来应该是空的。 如果有结果，说明纳税人识别号在导入过程中被当成数字处理了，后几位已经变成 0，且不可恢复——只能回去把字段类型改成文本重新导。同理可以检查 LENGTH(payer_account)。

这一步花三十秒，能避免后面所有基于错误编号的关联全部失效。

6.4 五句由浅入深的 SQL

下面的语法以 SQLite 为主（练手最方便），MySQL / SQL Server / PostgreSQL 的差异见 6.5。你可以直接粘进 DBX 的查询编辑器执行，也可以把业务需求说给 AI 助手，让它替你写。

① 先确认三张表能连上

SELECT
    a.customer_name   AS 客户名称,
    i.invoice_no      AS 发票号,
    i.invoice_date    AS 开票日期,
    i.amount          AS 不含税金额,
    i.tax_amount      AS 税额
FROM invoices i
JOIN ar_ledger a
  ON a.customer_code = i.customer_code
ORDER BY a.customer_name, i.invoice_date;

能出结果，说明"客户编码"这条关联链是通的。如果出来是空的，先查两边的 customer_code 是不是有前后空格或大小写差异。

② 算账龄

SELECT
    a.customer_name   AS 客户名称,
    i.invoice_no      AS 发票号,
    i.invoice_date    AS 开票日期,
    i.amount          AS 发票金额,
    CAST(JULIANDAY('now') - JULIANDAY(i.invoice_date) AS INTEGER) AS 账龄天数,
    CASE
        WHEN JULIANDAY('now') - JULIANDAY(i.invoice_date) <= 30 THEN '1-30天'
        WHEN JULIANDAY('now') - JULIANDAY(i.invoice_date) <= 60 THEN '31-60天'
        WHEN JULIANDAY('now') - JULIANDAY(i.invoice_date) <= 90 THEN '61-90天'
        ELSE '90天以上'
    END               AS 账龄区间
FROM invoices i
JOIN ar_ledger a
  ON a.customer_code = i.customer_code
ORDER BY 账龄天数 DESC;

③ 找出开票超 90 天、且找不到对应回款的发票

这就是领导要的催收清单：

SELECT
    a.customer_name   AS 客户名称,
    i.invoice_no      AS 发票号,
    i.invoice_date    AS 开票日期,
    i.amount          AS 发票金额,
    CAST(JULIANDAY('now') - JULIANDAY(i.invoice_date) AS INTEGER) AS 逾期天数
FROM invoices i
JOIN ar_ledger a
  ON a.customer_code = i.customer_code
WHERE NOT EXISTS (
        SELECT 1
        FROM bank_receipts r
        WHERE r.payer_name   = a.customer_name
          AND r.amount       = i.amount
          AND r.receipt_date >= i.invoice_date
      )
  AND CAST(JULIANDAY('now') - JULIANDAY(i.invoice_date) AS INTEGER) > 90
ORDER BY i.amount DESC;

NOT EXISTS 的意思是"在流水表里找不到任何一条能对上的回款"。这种"找缺失"的需求，在 Excel 里要靠 COUNTIFS 加辅助列绕好几道，SQL 里就是一句。

④ 按客户 + 账龄区间汇总——这张就是交给领导的表

WITH aged AS (
    SELECT
        a.customer_name,
        i.invoice_no,
        i.amount,
        CAST(JULIANDAY('now') - JULIANDAY(i.invoice_date) AS INTEGER) AS days
    FROM invoices i
    JOIN ar_ledger a
      ON a.customer_code = i.customer_code
)
SELECT
    customer_name                                                     AS 客户名称,
    COUNT(invoice_no)                                                 AS 发票笔数,
    ROUND(SUM(amount), 2)                                             AS 开票总额,
    ROUND(COALESCE(SUM(CASE WHEN days <= 30              THEN amount END), 0), 2) AS 三十天内,
    ROUND(COALESCE(SUM(CASE WHEN days BETWEEN 31 AND 60  THEN amount END), 0), 2) AS 三十一到六十天,
    ROUND(COALESCE(SUM(CASE WHEN days BETWEEN 61 AND 90  THEN amount END), 0), 2) AS 六十一到九十天,
    ROUND(COALESCE(SUM(CASE WHEN days > 90               THEN amount END), 0), 2) AS 九十天以上
FROM aged
GROUP BY customer_name
ORDER BY 九十天以上 DESC;

跑完点右上角导出成 Excel，底稿就有了。

作为参照：上面这句汇总，在 8 万行发票明细的样本数据上实测耗时 0.12 秒（普通笔记本、SQLite 内存库）。同样的数据量在 Excel 里靠公式做，光是重算就得等半分钟以上，而且十有八九会卡到没响应。这就是"该上数据库"的分水岭。

实际耗时跟数据量、索引、机器配置和数据库类型都有关，上面只是一个数量级参考，不代表你的环境一定这么快。

⑤ 客户层面的开票与回款差额比对

SELECT
    a.customer_name                                          AS 客户名称,
    ROUND(COALESCE(inv.inv_total, 0), 2)                     AS 开票总额,
    ROUND(COALESCE(rcv.rcv_total, 0), 2)                     AS 回款总额,
    ROUND(COALESCE(inv.inv_total, 0) - COALESCE(rcv.rcv_total, 0), 2) AS 差额
FROM ar_ledger a
LEFT JOIN (
        SELECT customer_code, SUM(amount) AS inv_total
        FROM invoices
        GROUP BY customer_code
      ) inv ON inv.customer_code = a.customer_code
LEFT JOIN (
        SELECT payer_name, SUM(amount) AS rcv_total
        FROM bank_receipts
        GROUP BY payer_name
      ) rcv ON rcv.payer_name = a.customer_name
ORDER BY 差额 DESC;

小技巧：中文别名只写在最外层的 SELECT 里，子查询内部用英文。这样导出成 Excel 时表头是中文的，同时避免部分客户端对中文标识符要加引号的麻烦。

差额为正说明还欠款，为负说明多收了或者对方户名跟台账客户名对不上（后者更需要查，往往是名称不规范导致的漏匹配，比如"XX有限公司"和"XX有限责任公司"）。

6.5 换数据库要改哪里

上面的日期计算是 SQLite 写法，换成别的库只需要替换"算天数"那一段，其余逻辑完全一样：

不想记这些？直接在 DBX 的 AI 助手里说一句"用 MySQL 语法算开票日期到今天的天数"，它会给你。

6.6 一个必须说清楚的局限

上面第 ⑤ 句是客户层面的总额比对，这个口径是准确的。

但如果你想要的是"这一笔回款，具体核销了哪几张发票"——那是另一回事，靠 SQL 硬关联很容易算错。举例：同一客户有三张发票、两笔回款，金额各不相同，还发生了部分回款（一张发票分三次到账）。这种情况下，把回款简单分摊到发票上会产生重复计算或错误匹配。

正规的核销需要在库里单独维护一张核销关系表（记录"哪笔回款、核销了哪张发票、核销了多少金额"），这正是财务软件里"应收核销"模块在做的事。本文的 SQL 适合做分析、对账、找差异，不适合直接替代核销流程。 如果你的目标是后者，请优先使用财务系统自带的核销功能。

说清楚这一点，是因为工具再好，用错口径出的报表是要担责任的。

七、几句实话

DBX 不是万能的，它替代不了 Excel。

会计工作的核心载体仍然是 Excel，这不是缺点，是事实。DBX 解决的是另一类问题：当数据量大到 Excel 跑不动、当多张表需要关联查询、当同一份数据要反复被不同维度分析的时候，把它放进数据库，比在 Excel 里堆公式要稳得多。

几个使用建议：

• 导入前备份源文件。 导入操作是真实写入数据库的，DBX 的只读保护可以拦住一部分误操作，但数据库权限才是最终边界。
• 生产环境慎用。 直连财务软件后台生产库前，务必确认公司 IT 政策，优先申请只读账号，不要在生产库上做写入测试。官方文档也明确提示：生产环境使用前请确认目标连接、目标表和备份方案。
• “清空后导入"是破坏性操作。 它会先清空目标表再写入。不同数据库的事务语义不一样，失败时不能假设会自动回滚。除非你非常确定，否则用"追加"模式。
• 中途取消不保证回滚。 已经提交的批次数据会留在表里。
• 自动推断的字段类型只是建议。 金额、日期、编号这三类必须人工确认。

八、适合谁，不适合谁

建议试试 DBX，如果你：

• 经常要处理超过十万行的明细数据，Excel 已经卡到不行；
• 需要把多个 Excel 台账整合起来做关联分析；
• 想自己取数，但不会写 SQL，也不想每次都排 IT 的队；
• 电脑配置一般，或者没有管理员权限装重型软件；
• 单位在用国产数据库，找不到合适的客户端；
• 想学一点数据库技能，需要一个零成本、低门槛的练手工具。

可能不需要，如果你：

• 日常数据量在几万行以内，Excel 透视表完全够用；
• 已经在用 DBeaver PRO 或 Navicat，且团队有成熟的使用规范；
• 需要做复杂的数据建模、ETL 调度、存储过程开发——这些场景有更专业的工具。

写在最后

工具的价值不在于它有多强，而在于它能不能嵌进你现有的工作流。

会计人的工作流中心是 Excel，这一点短期内不会变。一个好的数据库工具，应该主动接住 Excel，而不是要求你先把自己的数据改造成它喜欢的样子。

DBX 在这件事上做对了。二十来 MB，免费，双击就装，Excel 直接拖进去就能建表——这个门槛低到，你今天下午就能试一次。

相关链接

• DBX 官网（含中文文档）：https://dbxio.com/cn
• GitHub 仓库：https://github.com/t8y2/dbx
• 表数据导入官方文档：https://dbxio.com/cn/docs/table-import

本文功能描述基于 DBX 官方文档及公开资料整理，工具迭代较快，具体以你所用版本的实际功能为准。DBeaver 相关对比基于其社区免费版；付费版功能有差异，已在正文中说明。