t8y2--dbx/docs/performance/memory-usage-audit.md

DBX 内存占用功能排查报告

日期：2026-06-11

结论摘要

本次排查结合了当前运行进程快照、前端 bundle 体积、以及主要功能的代码路径。当前进程里最大的 repo 相关内存占用是开发服务器 vite，RSS 约 442 MiB；这属于开发工具链占用，不应直接归因到 DBX 某个业务功能。

业务功能层面，最容易导致内存占用率升高的是这些路径：

1. 查询结果 / 表数据 DataGrid / 导出：高风险，结果集会在原始 rows、筛选索引、显示项、搜索命中、导出 rows、磁盘缓存转换中多份存在。
2. 数据对比 Data Compare：高风险，后端一次性持有源表和目标表全量数据，并构建 HashMap、diff、同步 SQL；前端也会保留完整 diff 和 sync plan。
3. Redis Key Browser：高风险，fetch all 和 value search 可能扫描并保留大量 key，同时维护 flat list、tree list、visible rows 和命令历史。
4. Mongo 文档表格视图：中高风险，documents 会转换成 DataGrid 的二维 rows，嵌套对象还会被 JSON.stringify，随后再进入 DataGrid 的派生结构。
5. 查询图表 QueryChart：中高风险，打开图表会加载 ECharts，并把查询结果再次映射为 x/y series 数组。
6. Schema / Object Browser / ER Diagram：中风险，连接树、补全缓存、schema 关系和图节点会随库规模增长。
7. QueryEditor 补全、AI Assistant：中低风险，通常不是首要来源，但长会话、多 tab、频繁补全或长聊天会持续积累状态。

当前进程快照

命令：

ps -axo pid,ppid,rss,vsz,comm,args | awk 'NR==1 || /dbx|vite|pnpm|tauri|WebKit|node_repl|electron|cargo/ {print}' | sort -k3 -nr | head -40

主要观察：

进程	RSS	说明
node ... vite --config apps/desktop/vite.config.ts --port 5173 --mode web	452,880 KB，约 442 MiB	当前最大 repo 相关进程，属于开发服务器和 HMR，占用通常高于生产包
com.apple.WebKit.WebContent	197,232 KB，约 193 MiB	WebKit 渲染进程，可能来自 Codex 内嵌浏览器或本地预览，需结合具体窗口确认
com.apple.WebKit.WebContent	165,872 KB，约 162 MiB	同上
com.apple.WebKit.WebContent	130,672 KB，约 128 MiB	同上
pnpm dev:web	52,352 KB，约 51 MiB	Vite 父进程

补充：target、node_modules 等目录体积是磁盘占用，不是运行时内存。当前 target 目录约 27 GiB，node_modules 约 543 MiB，主要影响磁盘空间和构建缓存，不直接解释内存占用率。

前端 Chunk 观察

当前 dist/assets 中较大的 JS chunk：

Chunk	大小	相关功能
index-C0boAXCG.js	600 KB	主应用入口
QueryChart-DxFWVk_s.js	548 KB	查询图表，包含 ECharts 相关逻辑
codemirror-Dy52TtRW.js	464 KB	SQL 编辑器
sql-formatter-BTQ26GQc.js	288 KB	SQL 格式化
DataGrid-kZSBZBlT.js	148 KB	查询结果表格
RedisKeyBrowser-CdulxmUR.js	60 KB	Redis key 浏览器
AiAssistant-BrEVPSc_.js	52 KB	AI 助手

Chunk 体积不等于运行时内存，但能提示哪些功能首次打开会引入较重依赖。这里 QueryChart 的包体明显偏大，且运行时还会复制查询数据到 ECharts option。

功能排名与占用来源

排名	功能	风险	主要占用来源	典型触发
1	查询结果 / 表数据 / DataGrid / 导出	高	查询 rows、inactive tab 缓存、DataGrid 派生数组、搜索命中、导出 rows、缓存序列化峰值	大查询结果、多结果 tab、客户端搜索、全量导出
2	数据对比 Data Compare	高	源表 rows、目标表 rows、HashMap、diff clone、sync statements、sync SQL、前端 selectable diff	大表对比、批量表对比、差异很多
3	Redis Key Browser	高	flat key list、tree key list、visible rows、checked set、命令历史	fetch all、value search、大 keyspace
4	Mongo 文档表格视图	中高	原始 documents、转换后的 grid rows、对象 JSON 字符串、DataGrid 派生数组	大 page size、宽文档、嵌套对象多
5	查询图表 QueryChart	中高	ECharts 依赖、xData、series data、pie data	大结果集打开图表、多 Y 轴列
6	Schema / Object Browser / ER Diagram	中	treeNodes、schema cache、completion cache、diagram tables / relationships	多库多 schema、超大表结构
7	QueryEditor 补全和诊断	中	CodeMirror、per-editor table/column/FK cache、语义诊断状态	多编辑器 tab、频繁触发补全
8	AI Assistant	中低	conversations、messages、Markdown/Shiki 高亮缓存	很长对话、代码块多
9	连接池 / Agent / JDBC / SSH	中低到中	后端连接、外部 driver/session、后台状态	打开很多连接或长时间不关闭

1. 查询结果 / DataGrid / 导出

这是最需要优先处理的业务路径。

代码证据：

• apps/desktop/src/stores/queryStore.ts:136 将 inactive 结果内存缓存上限设为 MAX_CACHED_RESULTS = 5。实际效果是当前 active tab 加最多 5 个 inactive tab 的结果仍可留在内存。
• apps/desktop/src/stores/queryStore.ts:1406 到 1410 只按 tab 数量淘汰 inactive 结果，没有按行数、列数或估算字节数淘汰。
• apps/desktop/src/components/grid/DataGrid.vue:518 到 530 即使没有本地列筛选，也会为所有 rows 构造一份索引数组。
• apps/desktop/src/components/grid/DataGrid.vue:2350 到 2374 会为显示行构造 displayRowRefs，2404 又映射成 displayItems。虚拟滚动减少 DOM 节点，但没有避免 JS 内存里存在全量派生数组。
• apps/desktop/src/components/grid/DataGrid.vue:2445 到 2467 客户端搜索会扫描所有显示行和列，并保存每个命中的坐标。
• apps/desktop/src/stores/queryStore.ts:1469 到 1592 导出时循环分页并 rows.push(...result.rows)，最终返回一个包含全量 rows 的 QueryResult。这会让导出期间出现明显内存峰值。
• apps/desktop/src/lib/tabResultCache.ts:129 到 146 在结果被转成列式 MessagePack 缓存时，会从 row-major rows 生成 column-major columnValues，恢复时又重建 rows。淘汰/恢复期间可能出现原始 rows、列式副本、编码 bytes 多份共存。

建议：

1. 将结果缓存从“最多 5 个 inactive tab”改为“按估算字节数 + tab 数”双上限，例如默认只保留当前 tab + 最近 1 到 2 个小结果；大结果立即落盘或只保留当前页。
2. DataGrid 内部避免为全量 rows 同时维护 localFilteredRows、displayRowRefs、displayItems。可改为基于索引的懒计算，虚拟滚动只生成可视范围 item。
3. 客户端搜索增加上限和渐进式扫描，例如只扫描当前页或前 N 行，超限提示用户改用 SQL 查询。
4. 导出改成 streaming writer，不返回包含全量 rows 的 QueryResult。CSV/Excel/JSON 都应边拉边写，避免 rows.push(...) 聚合。
5. 缓存落盘时避免 structuredClone、row-to-column、encode 同时叠加；可用分块序列化，或在清空原始引用后再进行后台转换。
6. 对 MAX_RESULT_PAGE_SIZE 做产品级收紧。当前最大可到 100,000 行，配合宽表和 DataGrid 派生数组会非常容易冲高内存。

2. 数据对比 Data Compare

这是第二个最高风险路径，而且会同时占用 Rust 后端和前端内存。

代码证据：

• crates/dbx-core/src/data_compare.rs:227 到 250 通过 tokio::try_join! 同时拉取源表和目标表 rows。
• crates/dbx-core/src/data_compare.rs:723 到 768 虽然按 batch 查询，但最终 rows.extend(result.rows) 聚合到一个 Vec<Vec<Value>> 后返回。
• crates/dbx-core/src/data_compare.rs:422 到 489 会把两边 rows 转为 compare rows，再收集到 HashMap/order，并 clone added / removed / modified 的 values。
• crates/dbx-core/src/data_compare.rs:376 到 400 会生成 sync_statements，再 join 成完整 sync_sql，SQL 文本本身也可能很大。
• apps/desktop/src/components/diff/DataCompareDialog.vue:413 到 418 会把 diff row 映射成 selectable diff。
• apps/desktop/src/components/diff/DataCompareDialog.vue:500 到 528 会把选中的 diff 发送给后端重建 sync plan。
• apps/desktop/src/components/diff/DataCompareDialog.vue:538 到 692 批量表对比会逐表 push 结果，最后 batchResults.value = results，完整 diff 留在前端状态里。

建议：

1. 对单表对比加硬上限，例如行数超过阈值时要求用户确认，或默认只对比 key/hash 摘要。
2. 改为按主键有序流式对比，避免源表和目标表全量同时驻留内存。
3. diff 明细分页加载，只在概览里保留计数和少量样例。
4. sync SQL 按需生成或流式下载，不在内存里长期保存完整 sync_sql。
5. 批量对比时完成一张表就释放中间 rows，只保留摘要；用户展开表时再加载明细。

3. Redis Key Browser

Redis 浏览器在大 keyspace 下容易膨胀。

代码证据：

• apps/desktop/src/components/redis/RedisKeyBrowser.vue:61 到 82 同时持有 flatKeys、treeKeys、checkedKeys、commandHistory 等状态。
• apps/desktop/src/components/redis/RedisKeyBrowser.vue:141 到 146 会从 tree 计算 visibleRows。
• apps/desktop/src/components/redis/RedisKeyBrowser.vue:154 到 177 会基于 flatKeys 重建或合并 tree。
• apps/desktop/src/components/redis/RedisKeyBrowser.vue:222 到 227 value search 会持续 scan，直到没有更多结果。
• apps/desktop/src/components/redis/RedisKeyBrowser.vue:285 到 299 fetchAll 会循环 scan，直到所有 key 加载完。
• apps/desktop/src/components/redis/RedisKeyBrowser.vue:387 到 389 命令历史追加后没有长度上限。

建议：

1. fetch all 加数量上限、内存提示和二次确认；默认不应全量加载百万级 key。
2. value search 改成最多加载 N 条，然后提示继续加载。
3. commandHistory 做 ring buffer，例如最多保留 200 条。
4. tree 结构尽量使用紧凑节点，避免同时保留 flat、tree、visible 三份完整数据。

4. Mongo 文档表格视图

Mongo 单页默认受 page size 控制，但表格模式会复制数据。

代码证据：

• apps/desktop/src/components/mongo/MongoDocBrowser.vue:35 保存原始 documents。
• apps/desktop/src/components/mongo/MongoDocBrowser.vue:122 到 154 将 documents 转成 DataGrid QueryResult，为所有文档推导 columns 并生成二维 rows。
• apps/desktop/src/components/mongo/MongoDocBrowser.vue:143 到 149 对对象字段执行 JSON.stringify，宽文档或深嵌套对象会扩大字符串内存。
• apps/desktop/src/components/mongo/MongoDocBrowser.vue:332 到 340 每次加载 page 后替换 documents。

建议：

1. 表格视图只展开顶层标量字段；对象字段延迟 stringify，用户展开单元格时再格式化。
2. Mongo 表格模式使用更小的默认 page size。
3. 对宽文档增加列数或单元格字符串长度限制。

5. 查询图表 QueryChart

QueryChart 的包体和运行时复制都偏重。

代码证据：

• apps/desktop/src/components/chart/QueryChart.vue:4 到 15 引入并注册 ECharts CanvasRenderer、Line、Bar、Pie、Grid、Tooltip、Legend。
• apps/desktop/src/components/chart/QueryChart.vue:29 numericColumns 会扫描 rows 判断数值列。
• apps/desktop/src/components/chart/QueryChart.vue:57 生成全量 xData。
• apps/desktop/src/components/chart/QueryChart.vue:69 到 72 pie chart 为每一行生成 { name, value }。
• apps/desktop/src/components/chart/QueryChart.vue:96 到 100 每个 Y 列都会再 map 一份 series data。

建议：

1. 图表默认只取前 N 行或采样，例如 5,000 行以内。
2. 多 Y 列时提示 series 数据量，超限则要求用户确认。
3. numericColumns 可以基于抽样判断，不需要扫描所有 rows。

6. Schema / Object Browser / ER Diagram

这类功能一般不会像大结果集那样瞬间冲高，但在多连接、多库、多 schema 长会话里会累积。

代码证据：

• apps/desktop/src/stores/connectionStore.ts 中维护 treeNodes、loadedTreeNodeChildrenIds、completionTablesCache、completionObjectsCache、completionColumnsCache、schemaListCache 等长期状态。
• 全局 completion cache 有 COMPLETION_CACHE_MAX = 50，但 schema tree 和已展开节点会随用户浏览而保留。
• apps/desktop/src/components/diagram/SchemaDiagramDialog.vue 会持有 diagram tables、positions、relationships、visible map，超大 schema 下会增长明显。

建议：

1. 对 schema tree 增加“清理连接缓存”入口。
2. 大 schema 的 ER 图只加载用户选择的表及一跳关系。
3. completion cache 继续保留上限，但 per-connection/schema tree 也应考虑 LRU 或手动释放。

7. QueryEditor 补全与 AI Assistant

这两块不是当前首要嫌疑，但长时间使用会有累积。

代码证据：

• apps/desktop/src/components/editor/QueryEditor.vue 每个编辑器实例维护 cachedTables、cachedCompletionObjects、cachedColumnsByTable、cachedForeignKeysByTable。
• CodeMirror、language packages、SQL formatter 是较大的编辑器相关依赖。
• apps/desktop/src/components/editor/AiAssistant.vue 维护 messages、conversations、mention cache，并使用 Markdown / Shiki 代码高亮。

建议：

1. 编辑器 per-tab cache 增加容量或生命周期限制，tab 关闭时确认释放。
2. AI conversations 只在当前会话保留最近 N 条渲染消息，旧消息可折叠或按需加载。
3. 代码高亮按可见消息懒加载，避免一次性渲染长历史。

优先优化清单

短期优先做：

1. 把查询结果缓存从 tab 数上限改成内存估算上限，先降低 inactive result 的保留数量。
2. 导出改为 streaming，避免在 fetchTabResultForExport 聚合全量 rows。
3. DataGrid 去掉或延迟 displayItems 全量数组，搜索命中做分批扫描和上限。
4. Data Compare 加行数阈值、确认提示和 diff 明细分页。
5. Redis fetch all、value search、command history 加上限。

中期优化：

1. Data Compare 改为主键有序流式对比或 hash 摘要对比。
2. tab result cache 改成分块序列化，减少落盘时的峰值副本。
3. QueryChart 加采样和最大点数。
4. Mongo table mode 对对象字段做懒格式化。

长期优化：

1. 加内存诊断面板，显示当前 tab rows、列数、派生索引数量、缓存结果数量。
2. 在开发和生产 Tauri 下分别采集 JS heap snapshot，建立固定的大数据压测场景。
3. 对 Rust 后端的 Data Compare、Agent cursor、JDBC session 做 heap / allocation profile。

需要进一步实测

本报告没有拿到用户实际数据库数据集，因此功能排序主要基于代码路径和当前进程快照。若要定位“现在”具体是哪一个功能占用最多，建议补跑以下场景：

1. 生产 Tauri 包下打开空应用，记录基线 RSS。
2. 执行 10k、50k、100k 行查询，分别记录 DataGrid 首屏、搜索、切 tab、导出时的 JS heap 和 RSS。
3. 对比 10 万、100 万行表，记录 Rust 进程峰值内存。
4. Redis 分别加载 10k、100k、1M keys，记录 flat/tree/visibleRows 的前端 heap。
5. Mongo 表格视图加载宽文档和深嵌套文档，比较 document mode 与 table mode。

如果只看当前代码风险，首要优化对象应是“查询结果/DataGrid/导出”和“数据对比”。