DBeaver需手动启用结果集分页：窗口→首选项→数据库→编辑器→数据查看器中勾选“启用结果集分页”，设置每页行数并取消“执行后自动获取全部结果”；该设置按连接独立生效，且与SQL的LIMIT属不同层级，须配合使用以避免内存溢出。
默认情况下，DBeaver 会一次性加载全部查询结果（除非你手动加了 LIMIT），数据量稍大就卡死、内存爆满、UI无响应——这不是 bug，是它的默认行为。要真正实现“分页查看”，必须关掉自动全量加载，启用结果集分页模式。
怎么开启结果集分页加载
DBeaver 不是靠 SQL 里的 LIMIT 实现分页浏览的（那是你写语句时控制的），而是靠 UI 层的「结果集分页」机制来按需拉取数据。这个开关藏得有点深：
- 打开 窗口 → 首选项 → 数据库 → 编辑器 → 数据查看器
- 勾选 启用结果集分页（Enable result set paging）
- 设置 每页行数（Rows per page），建议填
20或50（太大起不到分页效果，太小翻页频繁） - 取消勾选 在执行后自动获取全部结果（Auto-fetch all rows after execution）——这一步最关键，不关它，分页形同虚设
分页导航快捷键有哪些
开了分页后，光靠鼠标点“下一页”太慢。这些快捷键能直接跳转，实测比点按钮快 3 倍以上：
-
Ctrl+Shift+[：跳到第一页（首页） -
Ctrl+Shift+]：跳到最后一页（末页） -
Alt+PgUp：上一页 -
Alt+PgDn：下一页
注意：PgUp/PgDn 在 MacBook 上通常要配合 Fn 键；外接键盘若没独立方向键区，可能需要查厂商映射表。
为什么点了分页还是卡住或加载全量
常见原因不是配置错了，而是被其他设置覆盖了：
- 当前连接的「连接设置」里勾选了 自动提交（Auto-commit），且你执行的是带事务的查询（比如含
SELECT ... FOR UPDATE），DBeaver 会尝试预加载全部以保证一致性——此时应临时关闭自动提交 - 结果集标签页右上角有个小齿轮图标，点开后误启用了 获取全部行（Fetch all rows），它会无视分页设置强行拉完
- 驱动参数里加了
useCursorFetch=true但没配defaultFetchSize，某些 JDBC 驱动（如 PostgreSQL 的）会退化为全量加载 - 查询本身含子查询或 CTE，且优化器无法下推分页逻辑，DBeaver 只能先取全部再本地切片——这时得靠 SQL 层加
LIMIT/OFFSET或窗口函数
分页和 LIMIT 的关系到底是什么
它们完全不在一个层面，混用反而容易出错：
-
LIMIT是数据库执行层指令，影响实际返回多少行给客户端；DBeaver 分页是客户端 UI 层行为，在已有结果集上做切片显示 - 如果你 SQL 里写了
LIMIT 100，又在 DBeaver 开了分页（每页 20 行），那结果集总共就 100 行，翻到第 6 页就会空——它不会去数据库再拉下一批 - 真要查海量数据（比如千万级表），必须两者配合：
LIMIT控制单次网络传输量，DBeaver 分页控制 UI 渲染节奏；否则光一个SELECT *就可能把 JVM 堆撑爆
最易被忽略的一点：分页设置是**按连接配置的**，不是全局生效。换一个数据库连接（比如从 MySQL 切到 PostgreSQL），得重新进首选项里开一遍——很多人连了新库发现又卡住，就是忘了这步。
