DBeaver默认查询结果限200行，可通过三层配置调整：全局首选项（最大行数/获取行数）、连接级设置、SQL编辑器右上角临时开关；MySQL下还需禁用useCursorFetch并清理limit属性以防自动追加。
怎么改 DBeaver 查询结果默认返回行数
DBeaver 默认只返回 200 行，对快速验证 SQL 或看表结构来说太少了；但设太高又容易卡死或内存溢出。关键不是“设多大”，而是按场景分档控制：窗口 → 首选项 → 数据库 → 结果集 里调 最大行数 和 获取行数 两个参数。
-
最大行数：全局硬限制，超过此值就截断，不建议设为 0（无限制），尤其连生产库时容易拖垮客户端 -
获取行数：每次从数据库拉取的批量大小，影响滚动加载速度，默认 100，可调到 50～200 之间平衡响应与吞吐 - 开发查数据时推荐设
最大行数 = 500、获取行数 = 100；临时抽样用最大行数 = 20（配合快捷键Ctrl+Shift+P打开“执行计划”前先限流）
为什么改了没生效？常见配置失效原因
改完设置后执行 SQL 还是返回 200 行，大概率是被更优先级的配置覆盖了。DBeaver 的结果集行为由三层叠加决定：
- 全局首选项（
窗口 → 首选项 → 数据库 → 结果集）—— 对所有连接生效，但可被下层覆盖 - 连接级别设置（右键连接 →
编辑连接 → 初始化 → 结果集）—— 单独为某个数据库定制，比如对 Oracle 设最大行数 = 1000，对 MySQL 保持 200 - SQL 编辑器右上角的“结果集限制”开关（带数字的小图标）—— 临时覆盖，仅本次查询有效，容易被忽略
检查顺序：先看右上角图标是否被手动点成“200”；再进连接编辑页确认有没有独立配置；最后回全局首选项核对。
MySQL 连接下 LIMIT 被自动加上的坑
即使你把 最大行数 设成 500，执行 SELECT * FROM user 仍可能只看到前 200 行——这不是 DBeaver 截断，而是它在 MySQL 连接中默认启用了 useCursorFetch=true + 自动追加 LIMIT 的组合策略，尤其在旧版驱动（如 MySQL Connector/J 5.1）下更明显。
- 解决方法：编辑 MySQL 连接 →
驱动属性标签页 → 找到useCursorFetch设为false，同时删掉limit相关自定义属性（如有） - 副作用：关闭游标获取后，大数据量查询会一次性加载全部结果到内存，慎用于百万级以上表
- 验证是否生效：执行
SELECT 1; SELECT SLEEP(3); SELECT 2;，若第二条阻塞整个结果集刷新，说明游标已关闭
结果集分页和滚动性能的真实瓶颈在哪
很多人以为调大 获取行数 就能“翻页更快”，其实 DBeaver 的分页本质是客户端缓存 + 按需拉取，真正卡顿往往来自数据库侧：
- 没有
ORDER BY的查询无法稳定分页，DBeaver 滚动到底部时可能重复拉取或跳行 - Oracle/DB2 等需要显式游标支持的数据库，若驱动未启用
useServerPrepStmts=true，每次滚动都触发新 round-trip - MySQL 8.0+ 推荐开启
allowMultiQueries=true并配合rewriteBatchedStatements=true，否则分页语句无法复用预编译
最常被忽略的一点：结果集网格本身不支持“真分页”，它只是模拟滚动；要查第 10 万行之后的数据，必须依赖 SQL 层的 LIMIT offset, size 或数据库原生分页语法（如 PostgreSQL 的 OFFSET/FETCH），DBeaver 不会帮你重写 SQL。
