达梦数据库里怎么查当前数据库下有哪些模式？这个问题我接过好多回了，从刚毕业的开发到干了多年的DBA都问过。看似只要一条SELECT就能搞定，但真动起手来，空结果、权限报错、大小写绕来绕去，能卡一下午。今天一次性把查看模式的原理、SQL写法、连带操作和常见坑讲透。先给结论：查看模式其实就是查达梦的系统表或兼容视图，问题从来不在语句本身，而在于你对达梦元数据组织和权限边界的理解。这篇文章适合刚上手达梦的开发和运维，也适合从Oracle、MySQL迁过来的朋友做个对照。

1. 为什么需要"看模式"：几个真实场景先把需求讲透

1.1 接手存量库时的第一件事

我接手过一个用达梦做的业务系统，库里的表是分批迁移过来的，有的按业务模块建了不同的账号，有的图省事全建在同一个账号下，还有一批历史表没写前缀。当时最急的不是性能，而是搞不清这个库里到底有多少套"相对独立"的对象集合。每张表都有归属，归属的上层就是模式。你只有先拿到模式清单，才能继续做差异比对、权限梳理、归档策略。

如果你跟我一样是半路接手，第一步千万别急着分析表结构，先查模式列表。模式清单相当于一张"库内地图"，上面标好了所有对象的大分区。后续无论是统计表数量、找冗余对象，还是给新同事配权限，都必须先有这张地图。

1.2 定位"同名表"与"裸表"

第二个常见场景是，业务方拿着一条SQL过来说"这张表怎么查不到"，结果发现库里有三张同名表，分散在不同模式下。不指定模式时，达梦按当前用户对应的默认模式去解析表名，匹配不到就报"无效的表名"。如果你不知道库里有哪几个模式，遇到这种同名表冲突，连排查方向都没有。

还有一类是"裸表"问题：建表时习惯性漏掉模式前缀，表建完以为落在自己名下，结果因为当前会话的模式切换，落到了别的模式里。想看看到底散在哪，也得先在模式粒度做对象统计。

1.3 权限交接与账号梳理

给新同事开账号时，最常问的问题是：让他能查哪些模式的数据？需要哪几个模式的只读权限？你如果不能列出当前库全部模式，权限分配就只能靠猜。我见过一个项目，给普通账号开了连接权限，结果对方执行一条SELECT * FROM xxx，报"表或视图不存在"。他不是没权限，而是他对应的默认模式里根本没有这张表，表在另一个模式下。这种情况如果能提前看清模式清单，在授权时直接把对应模式的访问权限加上，就不会浪费一晚上排查。

所以，查看模式不是一句SQL那么简单，它是一个前置动作，服务于存量库盘点、对象归属分析、权限设计和日常排障。理解了这些场景，后面几条SQL才用得起来。

2. 达梦数据库里模式的底层逻辑：用户、模式、对象是如何绑定的

2.1 模式不等于用户，但默认又像用户

先理清概念。达梦中的模式（Schema）是一个命名空间，用来组织表、视图、存储过程、序列这些对象。用户（User）则是一个登录和权限管理的实体。在达梦里，用户与模式默认是一一对应的：创建一个用户时，系统会自动创建一个同名模式，这个用户就是该模式的属主。

这就带来一个容易混淆的点：你查到的模式列表往往和用户列表高度重合，于是很多人直接把"用户"当"模式"。其实它们是两个维度的东西。你可以单独用CREATE SCHEMA创建一个不与任何用户完全绑定的模式（但创建时通常要指定属主）。举个生活化的类比：用户是门禁卡，模式是房间的隔断。你有哪张卡决定了你能进哪些区域，隔断则决定对象摆在哪一格。

2.2 对象全名是"模式.对象"，缺省时落在当前模式

达梦里对象的完整引用方式是模式名.对象名。例如SELECT * FROM SALES.T_ORDER，这里的SALES就是模式名，T_ORDER是表名。如果你写的是SELECT * FROM T_ORDER，达梦会在当前模式下去找这张表，找不到就报错。

当前模式通常就是你登录用户的默认模式。比如你用账号DBA_USER登录，那么默认的当前模式一般就是DBA_USER。但会话中的当前模式可以被切换，所以"我以为我在A模式，实际上在B模式"这种问题非常常见。搞清楚对象全名机制后，你再看模式查询，就会明白为什么要用"模式名.表名"的方式来精确访问。

2.3 系统内置模式与普通模式并存

达梦的字典库通常还自带一些系统模式，名字上就能看出来，例如SYS、SYSDBA、SYSAUDITOR等。它们用来存放系统表、审计信息或内置工具对象。查询模式列表时，这些系统模式也会出现在结果里。做数据盘点的时候，要把它们和业务模式分开看，别把系统对象数量也算进业务表统计中。

2.4 元数据存哪里：一张核心系统表

达梦把库里的所有对象元数据集中存放在系统表SYSOBJECTS里。这个表里有几个关键列：ID、NAME、TYPE$、SUBTYPE$、SCHNAME等。其中TYPE$字段标记了对象的大类型，模式这个大类的标记值是'SCH'。所以最底层、最直接的模式查询就是在这个表里按TYPE$='SCH'过滤。

这也解释了为什么很多老DBA习惯查SYSOBJECTS而不是用视图。系统表信息全、实时性强，只要你理解它的字段含义，它比视图更"原汁原味"。

3. 查询模式的SQL全集：从系统表到兼容视图，逐个实测

3.1 最底层：SYSOBJECTS 表的精确定位

先上最硬核的写法。在达梦的disql或者管理工具的SQL窗口里执行：

SELECT NAME, ID, TYPE$, SUBTYPE$, CRTE_TIME FROM SYSOBJECTS WHERE TYPE$ = 'SCH' ORDER BY NAME;

这条语句会把当前数据库里所有模式对象列出来，包括系统模式和业务模式。NAME就是模式名，CRTE_TIME是创建时间。如果你只想看业务模式，可以加个过滤，排除典型系统模式前缀：

SELECT NAME FROM SYSOBJECTS WHERE TYPE$ = 'SCH' AND NAME NOT IN ('SYS', 'SYSDBA', 'SYSAUDITOR', 'SYSSSO') ORDER BY NAME;

注意TYPE$比较的时候，建议直接写大写字符串。达梦的字典表默认以大写形式存储对象名，如果你写成小写，在某些会话或字符集环境下可能匹配不到。这个坑后面我专门讲。

3.2 更温和的窗口：ALL_OBJECTS 与 DBA_OBJECTS

如果你觉得SYSOBJECTS字段太底层，可以用达梦提供的兼容视图。最常用的是ALL_OBJECTS，它把表、视图、索引、序列等都包含在内，每一行都带有OWNER字段，这个OWNER基本等价于模式名。要获得模式列表，直接取OWNER去重即可：

SELECT DISTINCT OWNER FROM ALL_OBJECTS ORDER BY OWNER;

这条语句有一个隐蔽特性：它能返回的模式，取决于当前用户对这些模式里的对象是否可见。也就是说，普通用户查出来的模式列表可能不全，只能看到自己有权访问的对象所属的模式。想看到全部模式，得用DBA_OBJECTS（需要具备相应管理权限）：

SELECT DISTINCT OWNER FROM DBA_OBJECTS ORDER BY OWNER;

还有一个和用户相关的视图ALL_USERS，它主要列出用户信息，达梦里模式和用户默认同名，所以也可以作为参考：

SELECT USERNAME FROM ALL_USERS ORDER BY USERNAME;

但要注意：ALL_USERS返回的是"账号"而非严格的"模式命名空间"。如果库里有独立创建的模式，可能不会出现在用户列表里。反过来，系统账号也可能有同名模式。所以严格来说，模式查询应以SYSOBJECTS或ALL_OBJECTS/DBA_OBJECTS为准。

3.3 兼容 SQL 标准：INFORMATION_SCHEMA.SCHEMATA

达梦提供了INFORMATION_SCHEMA标准视图，其中就有一个SCHEMATA视图，直接对应模式列表。我在DM8里实测过，可以正常使用：

SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA ORDER BY SCHEMA_NAME;

这个写法最小白友好，普通权限用户也能查询到当前可见的模式集合。它和ALL_OBJECTS类似，可见范围受权限影响。如果你只是日常开发，想知道"我现在能碰哪些模式"，用这条就够了。别把它当成全量列表，全量还是要靠管理员跑DBA_OBJECTS。

3.4 顺手确认当前模式：CURRENT_USER 与 USER

很多时候，你需要的不是整个库的所有模式，而是"当前会话到底处于哪个模式"。这一点在排查"表不存在"问题时特别有用。直接用：

SELECT USER;

或者：

SELECT CURRENT_USER;

两条语句返回的都是当前登录用户，也就是默认的模式上下文。如果当前会话做过模式切换，CURRENT_USER表示的是当前生效的用户身份，模式上下文可能随之变化。更精确地确认当前默认模式，可以在INFORMATION_SCHEMA.SCHEMATA里匹配当前用户：

SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME = CURRENT_USER;

这能帮你快速判断：我写的裸表名，到底会被达梦放进哪个模式里解析。

3.5 一条SQL记住全部方法

为了留档方便，我把常用方法整理成表格：

4. 查询模式后的高频操作：统计表数量、切换模式、批量授权

4.1 统计每个模式下的对象数量，找出"元凶"

拿到模式清单，下一步通常就是统计每个模式里有多少表，看看数据都集中在哪。一条语句就能搞定：

SELECT OWNER, COUNT(*) AS TABLE_COUNT FROM ALL_TABLES GROUP BY OWNER ORDER BY TABLE_COUNT DESC;

如果你想统计所有对象（表、视图、索引等），可以对ALL_OBJECTS做分组：

SELECT OWNER, OBJECT_TYPE, COUNT(*) FROM ALL_OBJECTS GROUP BY OWNER, OBJECT_TYPE ORDER BY OWNER, OBJECT_TYPE;

这种统计在排查"某个模式是不是被垃圾表撑爆了"的时候特别好用。我遇到过一个场景：业务方说库变慢了，一统计发现其中一个模式里有上千张临时表，全是某段程序循环建的，一直没有清理。没有模式维度的对象统计，这种问题很难快速定位。

4.2 在SQL中切换/指定模式，不要再写错表名

知道有哪些模式，实际操作时还要学会怎么用。最稳妥的用法，永远是显式写"模式.表名"：

SELECT * FROM SALES.T_ORDER WHERE ORDER_ID = 1001;

如果你的需求是在当前会话切到另一个模式，让后续的裸表名都按该模式解析，可以用达梦的SET SCHEMA命令：

SET SCHEMA SALES;

执行之后，当前会话的默认模式就切到了SALES，再写SELECT * FROM T_ORDER就能直接查到。需要注意，SET SCHEMA通常只影响当前会话，断开重连后回到登录用户的默认模式。

有人会把它和ALTER USER混淆。SET SCHEMA是会话级别的临时切换，不需要修改用户定义，适合在交互式排障时用。等确认表确实在某个模式下，再把对应的授权和默认模式关系理清。

4.3 利用模式名拼动态SQL批量处理

模式列表最有价值的用法，是基于它生成动态SQL，做批量统计或授权。比如给一批模式里的所有表做统计，可以先用查询模式列表，再逐个拼接：

SELECT 'SELECT ''' || OWNER || ''' AS SCHEMA_NAME, COUNT(*) AS CNT FROM ALL_TABLES WHERE OWNER = ''' || OWNER || '''' FROM (SELECT DISTINCT OWNER FROM ALL_OBJECTS);

把输出的每行SQL拷贝执行，就能得到每个模式下的表数量。更进一步，可以用达梦的存储过程配合游标循环，动态拼接授权语句：

BEGIN FOR rec IN (SELECT NAME FROM SYSOBJECTS WHERE TYPE$ = 'SCH') LOOP EXECUTE IMMEDIATE 'GRANT SELECT ON ' || rec.NAME || '.T_ORDER TO APP_USER'; END LOOP; END;

动态SQL的核心好处是，你的模式列表一旦变化，脚本自动跟着走。比起手写几十条重复语句，省时还不容易漏。

4.4 创建模式：反向理解"查看"

要深入理解查看模式，最好也动手建一个。达梦创建模式的语法很直观：

CREATE SCHEMA DEMO_SCHEMA AUTHORIZATION DBA_USER;

这里DEMO_SCHEMA是模式名，DBA_USER是属主用户。建完后用前面的任意一种查询方法，就能在模式列表里看到它。反向操作一次，你对SYSOBJECTS里那条TYPE$='SCH'记录是怎么来的，就有了直觉。再配合SET SCHEMA切过去建表，整个"模式"概念就通了。

5. 我在真实环境里踩过的坑：查询结果差异、大小写和权限陷阱

5.1 结果为空？先查权限而不是先查语法

不止一个人拿SELECT DISTINCT OWNER FROM DBA_OBJECTS来跑，结果返回"权限不足"或干脆空集合，第一反应是自己SQL写错了。实际上，普通用户默认没有访问DBA_*视图的权限，所以跑不出来很正常。

如果你觉得自己应该有权限却查不到，先执行：

SELECT * FROM SESSION_ROLES;

看看当前会话带了哪些角色。没有DBA相关角色，DBA_OBJECTS就别指望了。这时候要么换用ALL_OBJECTS，要么让管理员给你加权限。排查原则：先确认你能看什么，再决定用哪个视图，而不是所有查询都一把梭。

5.2 大小写：双引号小写模式名怎么都查不到

达梦默认把未加引号的对象名转换为大写存储，但如果你建表或建模式时用了双引号，比如：

CREATE SCHEMA "mySchema";

那么它在SYSOBJECTS里存的NAME就是mySchema，小写。这时你用WHERE NAME = 'MYSYSCHEMA'去查，自然查不到。正确做法是保持大小写完全一致：

SELECT NAME FROM SYSOBJECTS WHERE TYPE$ = 'SCH' AND NAME = 'mySchema';

所以我建议：如果不是特殊需求，业务模式统一用大写或不用引号，省得后面所有的查表、授权、OCI调用都要带着别扭的大小写。

5.3 不同版本视图覆盖度不一样

达梦不同版本对标准视图的支持有差异。老版本可能没有INFORMATION_SCHEMA.SCHEMATA，或者ALL_OBJECTS里的字段略有不同。这时候最保险的是降级到SYSOBJECTS，因为它作为核心系统表，各个版本都稳定存在。跨版本排查时，先跑一条SELECT * FROM SYSOBJECTS WHERE TYPE$='SCH'看看结果结构，再决定用不用兼容视图。

5.4 一个实用的自查脚本

最后分享一个我常用的自查脚本，一条SQL同时查模式名、表数量、视图数量，适合接到新库时快速摸底：

SELECT OWNER AS SCHEMA_NAME, SUM(CASE WHEN OBJECT_TYPE = 'TABLE' THEN 1 ELSE 0 END) AS TABLES, SUM(CASE WHEN OBJECT_TYPE = 'VIEW' THEN 1 ELSE 0 END) AS VIEWS, COUNT(*) AS TOTAL_OBJECTS FROM ALL_OBJECTS GROUP BY OWNER ORDER BY TOTAL_OBJECTS DESC;

如果是以管理员身份跑，把ALL_OBJECTS换成DBA_OBJECTS，得到的就是全库视角。执行后你会看到一张清晰的对象分布表，哪个模式重、哪个模式轻，一眼就清楚。

5.5 权限边界：用户名、模式名"看似相同"的误导

还有一个很容易踩的坑：用户列表里有APP_USER，模式列表里也有APP_USER，你以为它们是同一个，于是给APP_USER授权让它访问APP_USER模式。结果某一天业务方说这账号查不到某张表，你才发现那张表其实在LEGACY_USER模式下，只是因为当时用管理员账号建表时没改模式，落到了其他模式下。

所以，任何时候都要把"模式"当成一个独立的命名空间去检查，而不是想当然地和用户划等号。查看模式只是第一步，接下来的每一条表级查询、授权操作，都要显式地用模式名.表名，才能避免这类混乱。

最后说两句实际体会

用达梦查模式这种事，看似简单，但真正遇到问题时，拼的是对元数据表的理解和对权限模型的认识。我自己习惯的做法是：平常开发用INFORMATION_SCHEMA.SCHEMATA，因为可读性好；需要做全库盘点和权限诊断时，老老实实回SYSOBJECTS查TYPE$='SCH'，再配合DBA_OBJECTS做对象统计。两条路搭配，既快又稳。

另外建议你拿到一个新库时，先把模式清单、每个模式的对象数量、当前账号能访问的模式这三个信息查出来存成一份笔记。之后遇到任何"表不存在""没权限"的报错，先对照这份笔记定位是模式没切对还是权限缺失，能省一大半时间。