根本原因是DBeaver未加载目标表所在schema/database，主因包括默认schema配置错误、元数据缓存未刷新、schema过滤器启用或用户权限不足导致静默跳过。
表在数据库里存在，DBeaver 里却搜不到
根本原因不是表丢了，而是 DBeaver 没加载到它——多数情况是当前连接默认指向了错误的 schema（MySQL 叫 database，PostgreSQL/Oracle 叫 schema），或者该 schema 根本没被选中加载。
常见现象包括：
- 执行
SELECT * FROM my_table;报错Table 'my_table' doesn't exist，但换用SELECT * FROM my_db.my_table;就能跑通 - 左侧导航树展开后，“Tables” 文件夹下空空如也，或只显示部分表
- 用搜索框输入表名，无任何结果，但确认该表确实存在于某库中
这不是数据丢了，是视图没对准位置。重点检查三件事：
- 连接配置里的「Default database/schema」是否填对了目标库名（比如 MySQL 填
my_app，PostgreSQL 填public） - 连接建立后，左上角状态栏是否显示了当前 active 的 schema（DBeaver 会把它标粗或加高亮）
- 右键点击连接 → 「Edit Connection」→ 「Connection settings」→ 确认「Initial schema」字段有值且正确
DBeaver 默认 schema 切换不生效
即使你在连接设置里改了「Default database」，刷新后仍看不到表？那大概率是元数据缓存没更新，或者 schema 过滤器在暗中起作用。
典型表现：
- 改完默认库并点「Finish」，重新连接，表还是不出现
- 手动执行
USE my_db;后查询正常，但导航树和搜索依然不识别 - 切换 schema 下拉菜单里没有目标库，或列表为空
排查顺序如下：
- 右键连接 → 「Refresh」（快捷键
F5），这是最常被跳过的一步 - 右键连接 → 「Edit Connection」→ 「Navigation Settings」→ 检查「Show system objects」是否勾选（某些驱动默认隐藏
information_schema等，连带影响 schema 列表） - 右键「Schemas」节点 → 「Filter」→ 查看是否有误启的表名或 schema 名过滤器（尤其容易遗忘的是历史配置的正则表达式）
- 如果用的是 PostgreSQL 或 Oracle，确认用户对该 schema 有
USAGE权限；MySQL 用户需有对应 database 的SELECT或更广权限
临时表、新建表搜不到的特殊处理
CREATE TEMPORARY TABLE 或刚 CREATE TABLE 完的表，在 DBeaver 里搜不到，不是 bug，是设计使然：DBeaver 的元数据加载基于连接初始化时的快照，不会自动感知会话级对象或未提交的 DDL。
例如：
- 执行
CREATE TEMPORARY TABLE tmp_log AS SELECT ...;后，tmp_log不会出现在导航树里（它本就不属于任何 schema） - 新建表后立刻搜索，可能因缓存未刷新而“失联”
- 某些驱动（如旧版 MySQL JDBC）对
INFORMATION_SCHEMA查询做了限制，导致新表元数据无法拉取
应对方式很直接：
- 临时表只能靠显式引用：
SELECT * FROM tmp_log;，别指望它出现在左侧树形结构里 - 新建表后，右键对应 schema → 「Refresh」，不是整个连接，是具体 schema 节点
- 若仍无效，尝试关闭「Metadata cache」：连接编辑页 → 「Driver properties」→ 找到
useInformationSchema设为false（MySQL 场景下有时更可靠）
权限不足导致表不可见的静默失败
DBeaver 不会明确报“你没权限看这个表”，而是直接跳过——表现为：库存在、schema 存在、但表列表为空，甚至 SHOW TABLES; 都返回空。
这种静默失败最容易误判为配置问题。验证方法很简单：
- 在 SQL 编辑器里执行：
SELECT table_schema, table_name FROM information_schema.tables WHERE table_schema = 'your_db'; - 如果返回空，说明当前用户连
information_schema的该 schema 条目都读不到，基本可断定权限缺失 - 对比命令行登录同一账号执行相同语句，若命令行能查到，那就是 DBeaver 驱动或连接参数触发了权限隔离（比如启用了
useSSL=true但服务端证书策略限制）
修复路径很窄：必须由 DBA 授予 SELECT 权限到 information_schema，或至少确保用户对目标 database 有 USAGE + SELECT（MySQL）或 USAGE on schema + SELECT on tables（PostgreSQL）。
最易被忽略的一点：DBeaver 的「Database Navigator」里看到的 schema 列表，本身也依赖 information_schema.schemata 查询结果——权限不够，连 schema 名都列不出来，更别说表了。
