企业官网建设流程全解析

做达梦数据库运维和开发的朋友，十有八九都碰到过这么一个问题：拿到一个达梦实例的连接串，登录进去之后想第一时间摸清楚“当前数据库下到底有哪些模式（Schema）”。尤其是从 MySQL 或 Oracle 迁移过来的团队，对达梦“用户即模式”的这套玩法不熟，常常把模式查错成表空间，或者满世界找“数据库列表”找不到。我去年接手过一套达梦库的运维交接，光是核对模式归属就折腾了大半天，后来我把常见的模式查询 SQL 整理成了一个脚本，从此再也没为这事发过愁。

这篇文章就把这套东西完整分享出来。你不需要有任何达梦基础，跟着一步步来就行：先搞懂模式在达梦里的准确定义，再看四条能查出模式清单的 SQL 写法和适用场景，然后我会用真实登录环境演示一遍完整执行过程，最后把权限报错、大小写坑、客户端工具看不到模式这些高频问题一次性讲透。看完你至少能在五分钟内回答出“当前实例下有哪些模式、每个模式里有什么对象、我有没有权限看到它们”。

1. 模式在达梦里到底是个什么概念

1.1 用户和模式：一枚硬币的两面

很多从 MySQL 转过来的同学，第一反应是“模式是不是等于库”？这个类比在达梦里不完全成立。达梦的架构里，一个实例才是完整的数据库服务，实例下面直接挂模式（Schema），没有 MySQL 那种“数据库”的中间层级。你可以把达梦的实例理解成一栋办公楼，模式就是楼里的一个个办公室，办公室里摆了各种东西——表、视图、存储过程、索引，全都是对象。

达梦里模式最特别的地方，在于它和用户是强绑定关系。你用CREATE USER创建一个用户时，达梦会自动创建一个和用户名同名的模式；反过来，你用CREATE SCHEMA显式建模式时，也必须指定一个归属用户。这意味着：查清楚了系统里有哪些用户，基本就等于查清楚了有哪些模式，二者是一枚硬币的两面。

这一点和 Oracle 非常像，所以很多 Oracle 的查询习惯在达梦上能直接沿用。但也别照搬得太开心，达梦有自己的一些胆识和细节，比如初始化参数里配置了用户和模式的关联方式之后，行为会有变化，后面我会单独说。

1.2 默认的同名绑定与特殊情况

达梦默认情况下，用户和模式一一对应、名称完全一致。你创建APP_USER用户，它就自带APP_USER模式；你连上数据库之后，默认的当前模式就是你登录账号对应的那个模式。

但有两类特殊情况必须注意。

第一种是显式创建模式并指定归属。你可以执行CREATE SCHEMA TEST_SCHEMA AUTHORIZATION APP_USER;，这样就会在APP_USER名下多出一个叫TEST_SCHEMA的模式。此时用户和模式不再是一对一，一个用户下可以挂多个模式，查询模式清单时如果只盯着用户列表看，就会漏掉这种额外模式。

第二种是达梦的兼容模式设置。达梦支持 Oracle 兼容、MySQL 兼容、SQL Server 兼容等不同兼容性，某些初始化参数会影响系统视图的返回内容，比如在 MySQL 兼容模式下，“模式”这个概念会更贴近“数据库”的体感。但好消息是，无论兼容模式怎么切，ALL_USERS、ALL_OBJECTS这类标准视图都能正常查询，模式清单的获取思路不受影响。

1.3 盘点模式清单的真实业务场景

为什么要费劲去查模式清单？我列举几个自己在工作中真实遇到的场景。

接手环境时做资产盘点。公司让你维护一套新接手的达梦系统，你连上去的第一件事肯定不是看 SQL 跑得慢不慢，而是先搞清楚这库里到底有哪些业务模式、每个模式有什么表、一共有多少数据量。没有这份清单，后面所有排查都像闭眼摸象。

数据迁移或同步前检查目标端。从 Oracle 导数据到达梦、或者达梦之间做数据同步，模式是否齐全、目标模式是否存在，决定了迁移脚本能不能一次性跑通。我见过不止一次因为目标端少建了一个模式，导致整批数据装载失败。

排查“表找不到”的归属争议。业务方报错说表不存在，但表明明就在库里。这种十有八九是表建在了别的模式下面，应用账号访问不到。这时候一条模式清单 SQL，比翻半天应用配置快得多。

权限审计。有些模式是历史遗留，创建用户的人早就离职了，但你得靠模式清单去发现这些“僵尸账号”，然后决定要不要锁定或删除。

2. 四条查模式的 SQL，按场景挑着用

2.1 查 ALL_USERS / DBA_USERS：最直接的字典视图法

达梦兼容 Oracle 的字典视图，所以最常规的写法是查用户。代码很简单：

-- 查看当前用户可见的用户列表（含系统内置用户） SELECT USERNAME FROM ALL_USERS ORDER BY USERNAME;

普通用户执行这条语句，看到的基本是系统内置账号和自己；如果业务上给其他用户授过某些权限，可能会多看到几个。想要更完整的字段，比如账户状态、默认表空间，可以查DBA_USERS，但前提是你需要有足够的系统权限：

-- 需要 DBA 或相应系统权限 SELECT USERNAME, ACCOUNT_STATUS, DEFAULT_TABLESPACE, CREATED FROM DBA_USERS ORDER BY USERNAME;

为什么先推查用户？因为达梦的默认机制就是用户模式同名，ALL_USERS的返回结果能直接当作模式清单用。拿到结果后，把SYS、SYSDBA、SYSSSO、SYSAUDITOR这类系统内置账号从清单里剔除，剩下的基本就是业务模式。这套方法是四类里最直观、最不容易出错的，也是我最推荐新手首先尝试的。

2.2 查 ALL_OBJECTS / DBA_OBJECTS：按对象归属反推

第二种思路不是查用户，而是从“对象归属于哪个模式”这个维度去反推。因为模式存在的意义就是承载对象，只要把全库所有对象的OWNER字段去重，拿到的就是一份“实际有对象的模式清单”：

-- 普通用户查自己可见的对象 SELECT DISTINCT OWNER FROM ALL_OBJECTS WHERE OWNER NOT IN ('SYS', 'SYSDBA') ORDER BY OWNER; -- DBA 视角查全库对象 SELECT DISTINCT OWNER FROM DBA_OBJECTS WHERE OWNER NOT IN ('SYS', 'SYSDBA') ORDER BY OWNER;

这里用到了 SQL 里常见的DISTINCT去重，作用就是让同一个模式只出现一次。相对于直接查用户，这个方法有一个明显优势：它反映的是“真实存在对象”的模式，那些建了用户但一张表都没建的空模式，不会出现在结果里。对想做数据盘点的朋友来说，这反而更贴合业务实际。

还可以再进一步，统计每个模式下各类型对象的数量：

SELECT OWNER, OBJECT_TYPE, COUNT(*) FROM DBA_OBJECTS WHERE OWNER NOT IN ('SYS', 'SYSDBA') GROUP BY OWNER, OBJECT_TYPE ORDER BY OWNER, OBJECT_TYPE;

这段执行完，哪个模式下有几张表、几个视图、几条存储过程，一目了然。我给客户做数据库巡检时，这条 SQL 是必跑的，比单纯查模式清单信息量大得多。

2.3 翻 SYSOBJECTS 系统表：底层玩法

如果你习惯和系统表打交道，达梦的核心系统表是SYSOBJECTS，里面记录了所有对象的元数据，包括模式、表、视图、索引等。直接查它也能拿到模式清单：

SELECT NAME, ID, PID, TYPE$, CRTDATE FROM SYSOBJECTS WHERE TYPE$ = 'SCH' ORDER BY NAME;

TYPE$字段表示对象类型，常见取值包括：SCH（模式）、TAB（表）、VEW（视图）、IDX（索引）、TRG（触发器）、PRO（存储过程）、PKG（包）等。这是达梦内部最底层的数据字典，查询它对权限的要求相对较低，有些情况下普通账号也能看到不少元数据信息。

不过我要提醒一句：系统表的字段含义和版本相关，比如TYPE$的取值在不同 DM 版本上可能有细微差异，生产环境用之前最好先在你当前的版本上验证一下。日常巡检，我个人更推荐先把 2.1 和 2.2 的字典视图方案跑通，系统表方案作为补充和交叉验证。

2.4 只看当前会话模式：最快但范围最小

有时候你不需要全库清单，只想知道“我现在连的是哪个模式”，一条语句就够：

-- Oracle 兼容写法 SELECT USER FROM DUAL; -- 达梦单独执行也能出结果 SELECT USER; -- 部分版本还支持查看当前 schema SELECT CURRENT_SCHEMA FROM DUAL;

需要特别说明的是，CURRENT_SCHEMA返回的是当前会话生效的 schema，它可能受SET SCHEMA操作影响，不一定等于你登录时用的用户名。比如你用SYSDBA登录后执行了SET SCHEMA APP_USER，再查CURRENT_SCHEMA得到的可能就不是 SYSDBA。这点排查问题时要留个心眼。

2.5 四种方法怎么选

这四种方法不是互斥的，实际工作中我经常组合使用：先用 ALL_USERS 拿到全量用户列表，再用 DBA_OBJECTS 统计对象分布，最后用 SYSOBJECTS 交叉验证一下，基本就不会出错了。

3. 实操全过程：从连接到出结果

3.1 连接达梦的几种方式

达梦的客户端工具有好几套，我常用的是这三种。

第一种是 disql 命令行。达梦自带的命令行客户端，和 Oracle 的 sqlplus 一个定位，适合脚本化和快速执行。在 Linux 上安装好达梦后，通常可以通过source环境变量文件或者手动设置DM_HOME来使用它：

export DM_HOME=/opt/dmdbms export PATH=$DM_HOME/bin:$PATH # 登录示例，注意 -p 参数和密码之间不要留空格 disql SYSDBA/\"123456\"@localhost:5236

如果数据库跑在 Windows 上，disql 一般位于安装目录的bin目录下，用法和 Linux 一致。连接端口默认是 5236，如果初始化实例时改过端口，这里要跟着改。

第二种是达梦图形化管理工具。Windows 上一般叫“达梦数据库管理工具”，Linux 桌面环境也有对应版本。图形工具适合鼠标点点点，能直接查看模式树、对象列表，排查问题时比命令行直观。

第三种是 DBeaver 这类通用数据库客户端。很多公司统一用 DBeaver，连接达梦时需要下载达梦官方 JDBC 驱动，URL 只有以下格式：

jdbc:dm://主机IP:5236

连接配置里填用户名和密码即可，默认会把你登录的用户名当成当前 schema。如果你的应用是 Java 项目，强烈建议先从 JDBC 层面把连接字符串测通，再往下游走。

3.2 完整执行与结果解读

假设我已经用 SYSDBA 登录，按顺序跑一遍查询。

先查 ALL_USERS：

SQL> SELECT USERNAME FROM ALL_USERS ORDER BY USERNAME; LINEID USERNAME ---------- -------------------------- 1 SYSAUDITOR 2 SYSDBA 3 SYSSSO 4 SYS 5 APP_USER 6 TEST_USER

达梦内置账号在不同版本里稍有区别，但SYS、SYSDBA、SYSSSO、SYSAUDITOR基本是固定的。剔除这四个系统账号，剩下的APP_USER、TEST_USER就是两个业务模式。

再用对象归属反推一遍：

SQL> SELECT DISTINCT OWNER FROM ALL_OBJECTS WHERE OWNER NOT IN ('SYS','SYSDBA') ORDER BY OWNER; LINEID OWNER ---------- -------------------------- 1 APP_USER 2 TEST_USER

两个结果对上了，说明这个实例下一共有两个模式，而且两个模式都至少有一个对象。如果 ALL_USERS 里有账号、ALL_OBJECTS 里没有它的任何对象，那就是一个空模式，后续如果应用连到空模式上提示找不到表，这个问题就得单独处理了。

最后看一眼自己当前在哪个模式：

SQL> SELECT USER FROM DUAL; LINEID USER ---------- ----------------------------- 1 SYSDBA

执行过程就这么简单，但每一步的输出都要学会看。尤其是 LINEID 这个列，达梦命令行输出的每行结果都会给一个序号，刚开始可能会被它吓一跳，其实它只是行号，不影响数据本身。

3.3 权限不够时的典型报错与处理

普通用户直接查DBA_USERS，大概率看到这样的结果：

SQL> SELECT USERNAME FROM DBA_USERS; [-2680]:No enough system privilege for the operation

错误码 -2680 表示没有足够的系统权限。解决思路有两条：

一是让管理员把 DBA 角色授予给你，操作简单但权限偏大，适合运维岗或临时排查：

GRANT DBA TO APP_USER;

二是精细授权，只授予查询特定视图的权限：

GRANT SELECT ON SYS.DBA_USERS TO APP_USER;

生产环境我强烈建议走第二条路，别随手丢 DBA 角色出去。DBA 角色能做的事太多，一个不小心就可能造成隐患。如果你只是要盘点模式，ALL_USERS通常已经够用了，先试试它，不行再考虑要权限。

4. 常见问题排查与避坑心得

4.1 为什么普通用户只能看到一部分模式？

这个问题被问过无数次。普通用户查ALL_USERS，默认只会显示系统内置用户和与自己相关的用户，别人创建的业务模式如果没有给你授予任何权限，你是看不到的。这是达梦权限模型的一部分，不是查询语句写错了。

遇到这种情况别急着怀疑 SQL，先确认自己用的是不是有足够权限的账号。如果只能用普通账号，那就联系 DBA 要一个只读权限，或者让 DBA 把查询结果导出给你。我遇到过有些刚入行的朋友，拿着应用账号去执行全库盘点 SQL，查不到东西就以为是环境问题，来来回回折腾一整天，最后发现是权限没给够。

4.2 模式名大小写和引号的坑

达梦默认会把不带引号的标识符转成大写存储，所有CREATE TABLE test实际建的表名是TEST。同样的规则也适用于模式名。如果你用带引号的写法构建了一个混合大小写的模式：

CREATE SCHEMA "TestSchema" AUTHORIZATION APP_USER;

那这个模式的名字就是TestSchema，之后查表必须加引号：

SELECT * FROM "TestSchema".T_USER;

平时最容易踩坑的场景是：别人建了一个带引号的模式，你用大写去查，怎么都查不到对象。遇到这种情况，先跑一遍SELECT NAME FROM SYSOBJECTS WHERE TYPE$='SCH'看清楚准确的名字，再决定后面怎么拼 SQL。达梦对大小写敏感的处理和 Oracle 一个路数，习惯了就好。

4.3 DBeaver/MyBatis-Plus 查不到模式怎么办

DBeaver 连达梦时如果驱动配置不对，或者左侧树没有刷新，会出现“能连上但看不到任何模式/表”的情况。解决办法有三步：

第一，使用达梦官方 JDBC 驱动，驱动 jar 版本要和数据库版本兼容。常见的是DmJdbcDriver18.jar，不同 DM 版本可能对应不同驱动，别混用。

第二，连接成功后右键数据库连接，选择“刷新”或者“重新连接”，让客户端重新拉取元数据。

第三，检查连接设置里的 Schema 选择。DBeaver 里通常会让你选默认 schema，选了错误的模式自然看不到别的模式下的表。

如果是 MyBatis-Plus 或 Spring Boot 项目，配置数据源时也要注意。达梦 JDBC URL 后面可以带 schema 参数，但部分版本支持得不稳定，最稳妥的做法是让连接用户本身就是目标模式用户，因为达梦默认用户和模式同名，这样框架层面就不需要额外指定 schema。要是代码里非要写 schema 前缀，记得用对了大小写，否则又是一顿好查。

4.4 养成保留“模式地图”脚本的习惯

最后分享一个我自己的实操习惯。我会在本地维护一个固定的达梦盘点脚本，里面放三条核心 SQL：ALL_USERS 拿用户清单、DBA_OBJECTS 统计对象分布、SYSOBJECTS 交叉验证模式列表。每次接手新环境，先跑一遍这个脚本，把结果导出成 CSV 存档，这就是这台实例的“模式地图”。

有了这份地图，后续再做数据迁移、权限审计、对象排查，效率完全是两个量级。我见过太多人每次遇到问题都重新敲一遍查询，临时看两眼又关掉，下次遇到还是从头来。数据库运维这种事，沉淀下来的脚本和文档，才是真正值钱的东西。

根据我个人经验，达梦的模式查询并不复杂，核心就是记住“用户模式同名”这个底层逻辑，再掌握 ALL_USERS、ALL_OBJECTS 这两个字典视图的用法。真正花时间的永远不是 SQL 本身，而是看懂结果、理解权限、避开大小写和兼容模式这些细节。把这篇文章里的四条语句复制到你的 GUI 工具或 disql 里跑一遍，对照着检查输出，你很快就能把这套流程变成自己的常规操作。