修改 dbeaver.ini 的 JVM 堆内存参数是第一步也是最关键的一步
绝大多数“打开大表就卡死”“编辑几万行后界面冻结”的问题，根源是 JVM 堆内存不足，触发频繁 GC 甚至 OOM。DBeaver 默认的 -Xmx1024m 在处理几十万行以上数据时完全不够用。
-
-Xms设太小（如默认64m）会导致启动后反复扩容，增加 GC 压力；建议设为最大堆的 1/3～1/2，例如-Xms1024m -
-Xmx必须按你机器物理内存和使用场景调整：8GB 内存机器至少配-Xmx2048m，16GB+ 可设-Xmx4096m；但别超过物理内存的 50%，否则系统会交换（swap），反而更卡 - 务必删掉过时的
-XX:MaxPermSize（JDK 8u212+ 已废弃），换成-XX:MaxMetaspaceSize=512m
改完保存，重启 DBeaver —— 这一步不重启无效，且多数人漏掉。
关闭自动加载全部数据，用分页或条件过滤代替“全量 SELECT *”
DBeaver 默认点击表名会执行 SELECT * FROM table_name，对百万级表等于直接拖垮 UI 线程。这不是 bug，是设计行为，必须主动干预。
- 右键表 → “查看数据” → 切换到“SQL”标签页，手动写带
LIMIT的语句，例如SELECT * FROM orders LIMIT 5000 - 在连接配置里启用“限制结果集行数”：编辑连接 → “初始化”选项卡 → 勾选“限制结果集行数”，设为
5000或10000 - 避免用“编辑”按钮直接进全量编辑模式；如需修改，先用 WHERE 筛出目标行，再右键“编辑所选行”
注意：fetchSize 参数（如 MySQL 的 useCursorFetch=true&defaultFetchSize=1000）只影响 JDBC 驱动拉取批次，并不能阻止 DBeaver 一次性把所有结果加载进内存渲染表格 —— 所以光调驱动参数没用，必须配合 LIMIT 或过滤。
禁用非必要插件，尤其 ER 图、NoSQL、AI 相关扩展
DBeaver 启动慢、开表卡，常因插件过多。官方完整版打包了 150+ 插件，但你可能只用 MySQL/PostgreSQL。每个插件都占用类加载、内存和后台线程。
- 进菜单【帮助】→【关于 DBeaver】→【安装详情】→【插件】列表，按“启动级别（startLevel）”排序，startLevel 越小越早加载；startLevel > 4 的插件（如
org.jkiss.dbeaver.ext.erd、org.jkiss.dbeaver.ext.ai）可直接禁用 - 删除
plugins/目录下不用的插件文件夹（如org.jkiss.dbeaver.ext.mongodb_*），比禁用更彻底 - 不要装第三方主题或美化插件，它们常劫持 UI 渲染链路，导致表格滚动延迟明显
禁用后重启，你会发现打开大表的初始响应时间从 8 秒降到 2 秒以内 —— 这不是错觉，是 OSGi 插件容器真实省下的初始化开销。
用“只读模式”打开大表，避免元数据自动刷新干扰
当你右键大表点“编辑”时，DBeaver 默认会同步刷新列注释、约束、索引等元数据。这些请求在表结构复杂时可能阻塞主线程，造成假死。
- 右键表 → “查看数据” → 勾选底部“只读模式”，此时不加载触发器、外键依赖等重型元数据
- 如果只是查数据，永远优先选“查看数据”而非“编辑”；“编辑”按钮本质是开启事务 + 全量元数据加载 + 行变更监听，代价远高于必要
- 在首选项中关闭自动刷新：【窗口】→【首选项】→【数据库】→【元数据】→ 取消勾选“自动刷新对象元数据”
真正容易被忽略的是：即使你没点“编辑”，只要开启了“延迟加载组件”（在【窗口】→【首选项】→【用户界面】里），DBeaver 仍会在鼠标悬停时偷偷加载列详情 —— 这个开关建议关掉，大表场景下它比开着还慢。
