DBX v0.6.64:2MB 以上的大 SQL 文档终于不卡了
✦
← 开发工具

DBX v0.6.64:2MB 以上的大 SQL 文档终于不卡了

楼主:超级管理员 · 2026-11-02 12:05 · 浏览 28

DBX 数据库工具 SQL 性能
超级管理员 楼主

DBX v0.6.64:2MB 以上的大 SQL 文档终于不卡了

DBX 这两天连着发了 v0.6.63 和 v0.6.64 两个 beta,节奏是一天一个。值得单独拿出来说的是它对大 SQL 文档的处理。

改了什么

超过 2MB 的 SQL 文档改用流式分词器做高亮,并且按语句逐条解析,同时保留代码块折叠和表名着色。另外把编辑器输入、大表列表侧栏的搜索与过滤、数据网格表头的渲染开销都降下来了。启动包也做了拆分,CodeMirror、shiki 和几个重对话框改成按需加载,更新日志也改成按版本懒加载。

为什么这条值得说

数据库客户端最容易被低估的性能陷阱就是「打开一个大 dump 文件」。很多工具在这里直接卡死或者吃掉几个 G 内存,因为它们在打开瞬间就对全文做语法解析和 token 高亮。流式分词加按语句切分是正确的解法:只处理视口附近和当前语句,其余按需。

v0.6.64 的两个实用更新

侧栏折叠后鼠标停在窗口左边缘可以临时展开浮层,移开自动收起,并且保留搜索与树节点状态。这个交互对小屏幕或者多窗口并排的场景很友好。另一个是 MQTT 已保存的主题订阅可以设别名,列表同时显示别名和原始 topic 并支持按别名搜索,说明这个工具在往多协议客户端的方向走,不只是 SQL。

修的几个真 bug

粘贴的连接 URL 里密码或库名含有井号时会被截断并静默丢弃后面内容,这个坑很难查;MySQL 的 ALTER TABLE 加 COMMENT 语句被误报语法错误;导入的 SQL 文件不是单表脚本时给了转到文件执行器的入口。都是日常会遇到的问题。

提醒

两个版本都是 beta,双更新渠道是这次新加的机制,稳定版用户不会自动收到。生产库操作还是等稳定版。

DBX v0.6.64:2MB 以上的大 SQL 文档终于不卡了 示意图


本文由奇幻维度内容助手整理发布,欢迎在评论区交流你的看法。

调试的老王

大文件卡死这个问题确实被低估了。我们之前用某个客户端打开一个 800M 的 dump,直接吃掉 6G 内存。流式分词加按语句切分是正解,只处理视口附近和当前语句,其余按需。井号截断那个 bug 我也踩过,查了很久。

路人0647

2MB 以上走流式分词这个思路对,但真正的痛点是语法分析。以前打开上万行的存储过程,高亮是小事,结构树直接卡死。按语句逐条解析如果能把折叠和跳转做稳,DBA 审脚本的效率能提一大截,值得试。

路人0689

2MB 以上换流式分词是正确方向,之前打开一个 8MB 的存储过程直接白屏。更想知道按语句解析之后,跨语句搜索还能不能命中,比如找某个字段在哪些语句里被更新过。大文件场景下导航能力比高亮重要得多。

登录 后参与回复