DBeaver 不支持原生连接 SQLite 内存数据库（:memory:），因内存库进程内隔离、每次连接新建空白实例，与 DBeaver 连接复用和元数据缓存机制冲突，导致表不可见、查询失败；推荐改用带 Delete on disconnect 的临时文件路径替代。
直接说结论：DBeaver 不支持原生连接 SQLite 内存数据库（:memory:），所有尝试填入 :memory: 或 jdbc:sqlite::memory: 的配置都会失败——不是报错就是连上后看不见任何表，甚至查询返回空结果。
为什么 DBeaver 无法连接 :memory: 数据库
SQLite 的内存数据库是“进程内、一次性、无持久化”的。每次 JDBC 连接建立时，:memory: 都会创建一个全新的、彼此隔离的空白库；而 DBeaver 在 UI 层做了连接复用和元数据缓存，它会反复重连、预加载表结构、执行 PRAGMA table_list 等操作——这些行为导致每次连接看到的都是一个全新空库，历史建表/插入完全丢失。
这不是配置错误，是 JDBC 驱动 + DBeaver 架构 + SQLite 内存模型三者冲突的必然结果。
- DBeaver 默认启用“自动提交”，但内存库在连接关闭时即销毁，没有 commit 概念
- DBeaver 的元数据浏览器依赖首次连接后的 schema 缓存，而后续查询可能落在新实例上
- 官方 SQLite JDBC 驱动（org.xerial:sqlite-jdbc）明确说明：
:memory:仅适用于单次短连接场景，不适用于图形客户端长期会话
:memory: 被拒绝时的典型现象
你可能会遇到这些表现，本质都指向同一个底层限制：
- 点击“测试连接”成功，但展开数据库节点后为空（无 catalog、无 schema、无表）
- 手动执行
CREATE TABLE test (id INTEGER)成功，再执行SELECT * FROM test报错[SQLITE_ERROR] SQL error or missing database (no such table: test) - 连接设置里填了
:memory:，DBeaver 却自动改回空路径或报path is not specified - 日志中出现
java.sql.SQLException: out of memory（实为驱动对内存库路径解析异常）
替代方案：用临时文件模拟内存库行为
如果你需要快速验证 SQL、避免磁盘写入、又想在 DBeaver 里完整操作，推荐这个经实测稳定的折中做法：
- 创建一个带随机后缀的临时文件路径，例如
/tmp/sqlite_tmp_abc123.db（macOS/Linux）或C:\Users\you\AppData\Local\Temp\sqlite_tmp_xyz.db（Windows） - 在 DBeaver 新建 SQLite 连接时，填入该路径 —— 它会自动创建空库
- 勾选连接设置里的
Delete on disconnect（断开连接时删除），这个选项在高级驱动属性里，需手动开启 - 使用完毕后，关闭连接，文件即被自动清理
这样既保留了 DBeaver 全功能（编辑器、可视化建表、导出、外键提示），又实现了“用完即焚”的轻量体验。注意：该选项依赖 JDBC 驱动版本 ≥ 3.42.0，旧版 DBeaver 自带驱动可能不支持，需手动更新驱动。
真要调试内存库？换 CLI 或代码里跑
如果逻辑必须基于 :memory:（比如测试扩展、验证事务隔离性、跑单元测试），请放弃 DBeaver：
- 用原生
sqlite3.exeCLI：启动即进内存库，.schema和SELECT都即时生效 - 用 Python / Java 写几行代码：通过
sqlite3.connect(":memory:")或DriverManager.getConnection("jdbc:sqlite::memory:")直接交互，配合 print 或 debugger 查看状态 - 别试图在 DBeaver 里“强行连”，它底层没做针对内存库的会话生命周期管理
最常被忽略的一点：DBeaver 的“连接”概念默认绑定到持久化路径，它的整个元数据服务、后台刷新、结果集缓存都建立在这个假设上。一旦脱离文件路径，它就从数据库工具退化成一个带语法高亮的 SQL 输入框——而这恰恰不是你打开 DBeaver 的初衷。
