接手过达梦数据库的人，十个里有八个会在梳理数据字典时撞上同一个问题：表建了一堆，注释到底存在哪？要是你还停留在“一张张表翻Designer属性”的土办法上，效率低得想骂人。其实达梦数据库早期的系统表设计里就预留了出口，systablecomments就是专门干这个的。它是一张存放表、视图等对象注释信息的系统表，你用COMMENT ON TABLE ... IS '...'写进去的那句话，最终就是落在这里。搞清楚它的结构和用法，你就能一条SQL把全库的表名注解都捞出来。这篇文章适合刚接触达梦的DBA、做数据治理的同学，以及要批量提取元数据的ETL开发，我会从定位、表结构、SQL实操一路讲到几个容易踩的坑，照着做基本能直接开工。
写注释和查注释看着是小事，但真到数据字典交付、主数据治理、或者RPA工具自动补字段说明的时候，这个系统表的价值一下就出来了。你不需要懂多少内部原理，只需要知道“注释这种东西被数据库放在哪个角落、怎么把它体面地取出来”就够了。
1. 一张系统表存了全库表的“昵称”：SYSTABLECOMMENTS的定位
1.1 先搞清注释在数据库里是怎么落地的
数据库里的注释（Comment）不是业务数据，而是描述数据的数据，也就是元数据。你执行COMMENT ON TABLE EMPLOYEE IS '员工信息表'，这条语句不会往业务表里插一行，而是由数据库内部去更新数据字典。达梦的数据字典并不是一张大表，而是由若干系统表组合而成，SYSTABLECOMMENTS就是专门承载表级注释的那块“登记簿”。
可以打个比方：业务表好比小区里的住户，系统表就像是物业的住户登记册。住户登记册不关心你家里摆几台冰箱，它只记录“哪个门牌号住着谁、有没有备注”。同理，SYSTABLECOMMENTS不关心表里有多少行数据，只记录“哪个表叫什么名字、写了什么说明”。
你可能会问：对象名称在SYSOBJECTS里不是已经有吗，为什么还要单独一张SYSTABLECOMMENTS？因为对象名是对象名，注释是注释。对象名是硬性标识，必须唯一且结构紧凑；注释则是给人看的自由文本，允许很长、允许为空、允许随时修改。如果都塞在对象主表里，主表会越来越臃肿，而且当注释被反复更新时，会影响对象管理本身的效率。单独拆表存放，是数据字典设计上的常见做法，也让“只查注释”这个高频需求不用去碰其他重字段。
1.2 为什么注释信息非要单独放一张系统表
从实际使用角度看，注释信息单独放表至少有三个好处。第一，批量查询方便。你要出一份全表清单，带注释的那种，直接扫这张表就行，不需要去解析建表语句或者扫描业务表。第二，权限隔离清晰。业务表数据可能对普通用户隐藏，但表注释这种元数据可以单独通过视图开放给有需要的人，不会牵扯到业务数据安全。第三，更新代价小。COMMENT ON语句只需要维护元数据索引，不触发业务表的日志和锁机制。
系统表在达梦中通常归属于系统模式，和普通业务表物理隔离。你在业务模式里看不到它，但只要权限到位，可以直接通过SYS.SYSTABLECOMMENTS访问。不同版本的可能在字段名上有一点差异，但整体定位是一致的。
1.3 它在达梦数据字典里的位置与其他系统表的关系
达梦的数据字典不是一个单一对象，而是多个系统表的协作网络。SYSOBJECTS相当于对象主表，记录数据库里每个对象的ID、类型、名称；SYSTABLES记录表存储层面的属性；SYSTABLECOMMENTS记录表级注释；SYSCOLUMNCOMMENTS则记录列级注释。它们之间通常通过对象ID或名称关联，但如果你只查注释，很多场景并不需要把主表拉进来。
我记得自己第一次接触达梦时，习惯性照Oracle的思路去查USER_TAB_COMMENTS，结果发现达梦也提供同名兼容视图，顿时少踩了很多坑。这就是达梦一个友好的设计：它既保留了自己的系统表，又兼容了Oracle风格的数据字典视图。你要理解系统表，就先把它放在“字典体系中的注释分表”这个位置，不要孤立地看。
2. 先掌握字段再写SQL：SYSTABLECOMMENTS表结构拆解
2.1 常见字段与含义
在动手写查询之前，建议你先执行一条命令看看当前环境的真实结构：
DESC SYS.SYSTABLECOMMENTS;以我接触过的达梦8系版本来看，这张表常见的字段大致是下面这些，但不同小版本可能有微调，所以 DESC 确认是最稳的做法。
| 字段名 | 类型 | 说明 |
|---|---|---|
| OWNER 或 SCHEMA_NAME | VARCHAR | 对象所属模式（Schema），通常就是用户名的意思 |
| TABLE_NAME | VARCHAR | 表名或视图名 |
| TABLE_TYPE | VARCHAR | 对象类型，常见有 TABLE、VIEW 等 |
| COMMENTS | VARCHAR | 注释文本，没有注释时为 NULL |
| 可能的 ID 字段 | BIGINT | 对象ID，主要用于关联其他系统表 |
你看到OWNER这个字眼时，别把它理解成“拥有者权限”，在达梦里它更接近“属于哪个模式”。查询时如果不加这个条件，遇到多个模式下存在同名表，结果就可能比你预期的多或者少。
2.2 大小写和空值这两个细节直接影响查询结果
达梦的对象名存储大小写策略和初始化参数有关。当成库时设置了大小写敏感（这是比较常见的行为），你在不带引号创建表时，对象名通常按大写存储；一旦表名用了引号，比如CREATE TABLE "Employee" ...，存储的名字就会保留你写的大小写。这意味着你执行：
SELECT * FROM SYS.SYSTABLECOMMENTS WHERE TABLE_NAME = 'employee';大概率查不到，因为实际存的可能是EMPLOYEE。我建议你在条件中统一写成大写，或者干脆用UPPER(TABLE_NAME)。
空值这个点更隐蔽。表没有注释时，COMMENTS字段存的是NULL，不是空字符串。所以在过滤“没注释的表”时，要写WHERE COMMENTS IS NULL，而不是WHERE COMMENTS = ''。很多新手在这里翻车，查了半天以为是系统表没记录，其实只是过滤条件用错了。
2.3 兼容视图：USER_TAB_COMMENTS等更省心
达梦为了让熟悉Oracle的人无缝切换，提供了一组兼容视图：USER_TAB_COMMENTS、ALL_TAB_COMMENTS、DBA_TAB_COMMENTS。这些视图的底层数据来源就是SYSTABLECOMMENTS等系统表，但它们在权限和可见范围上做了封装。
USER_TAB_COMMENTS：只显示当前用户自己模式下能看到的表注释。ALL_TAB_COMMENTS：显示当前用户有权限访问的所有模式下的表注释。DBA_TAB_COMMENTS：管理员视角，全库所有注释。
我自己工作时，默认优先用USER_TAB_COMMENTS或ALL_TAB_COMMENTS，只有需要排查数据字典本身的问题时，才去直接看SYS.SYSTABLECOMMENTS。视图的好处就是帮你省掉手动拼OWNER条件，也不会因为普通用户没有系统表权限而报错。
3. 从一条SQL到一份字典：查询表注释的三种实操方式
3.1 直接查系统表：先DESC再查询
如果你就是要看系统表的真实数据，可以这样操作。先确认字段，再查询：
-- 先看结构，确认你环境里的字段名 DESC SYS.SYSTABLECOMMENTS; -- 查询指定模式下指定表的注释 SELECT OWNER, TABLE_NAME, TABLE_TYPE, COMMENTS FROM SYS.SYSTABLECOMMENTS WHERE OWNER = 'SYSDBA' AND TABLE_NAME = 'EMPLOYEE';第一次跑出来可能让你有点失望，因为如果之前没给表配过注释，结果里的COMMENTS就是NULL。这不是SQL的问题，是表确实没有写注释。你可以换一张自己明确写过COMMENT ON的表来验证。
这里有一个经验：不要直接SELECT *，特别是系统表可能带一些内部关联字段，列多了反而干扰判断。先用DESC看清结构，再挑需要的字段。
3.2 用兼容视图：当前用户与全库两种视角
如果你只是要“把当前模式下所有表的注释拉出来”，用视图最简洁：
-- 当前用户模式下的所有表和注释 SELECT TABLE_NAME, TABLE_TYPE, COMMENTS FROM USER_TAB_COMMENTS WHERE TABLE_TYPE = 'TABLE'; -- 需要带模式名时，用 ALL 视图 SELECT OWNER, TABLE_NAME, TABLE_TYPE, COMMENTS FROM ALL_TAB_COMMENTS WHERE OWNER = 'SYSDBA';加上TABLE_TYPE = 'TABLE'是为了把视图、物化视图等对象过滤掉。如果你连视图注释也要，那可以把条件去掉，或者改成IN ('TABLE', 'VIEW')。
从这条路出发，其实你已经能满足大多数报表需求了。全库几十张表，一条SQL秒出清单，比人肉点GUI不知道高到哪里去了。
3.3 进阶：表注释联动列注释生成数据字典
很多时候光有表注释还不够，字段注释才是大头。达梦的列注释走的是SYS.SYSCOLUMNCOMMENTS，但也有兼容视图USER_COL_COMMENTS和ALL_COL_COMMENTS。我们可以把表注释和列注释拼起来，生成一份“带注释的数据字典”：
SELECT c.TABLE_NAME, tc.COMMENTS AS TABLE_COMMENTS, c.COLUMN_NAME, cc.COMMENTS AS COLUMN_COMMENTS FROM USER_TAB_COLUMNS c LEFT JOIN USER_TAB_COMMENTS tc ON c.TABLE_NAME = tc.TABLE_NAME LEFT JOIN USER_COL_COMMENTS cc ON c.TABLE_NAME = cc.TABLE_NAME AND c.COLUMN_NAME = cc.COLUMN_NAME WHERE c.TABLE_NAME = 'EMPLOYEE' ORDER BY c.TABLE_NAME, c.COLUMN_ID;这个SQL的核心是LEFT JOIN。为什么要用左连接而不是内连接？因为很多老表根本没有注释。如果内连接，没有注释的列会被直接过滤掉，而左连接至少能保证每个列都出现在结果里，注释留给NULL，你导出Excel后一眼就能看出哪些字段欠注释。
如果你用的是系统表而不是视图，那通常还要关联SYSOBJECTS去取对象ID。但实际操作中，视图已经帮你处理了这部分关联逻辑，也更不容易写错。
3.4 程序化获取：JDBC里的REMARKS
还有一种常见场景，是在Java应用里动态获取表的注释，用来生成代码注释或者做接口文档。很多人不知道，JDBC标准接口已经把这个能力内置了，根本不用手动拼系统表SQL。
DatabaseMetaData metaData = connection.getMetaData(); try (ResultSet rs = metaData.getTables(null, null, "EMPLOYEE", new String[]{"TABLE"})) { while (rs.next()) { System.out.println("表名: " + rs.getString("TABLE_NAME")); System.out.println("注释: " + rs.getString("REMARKS")); } }这里的REMARKS就是JDBC对注释的统一封装。达梦驱动实现了这套接口，所以直接调用就行。当然，如果你需要同时查多张表、或者要做复杂的过滤和批量导出，直接执行系统表SQL会更灵活。两种方式不冲突，看场景选择。
4. 能查到是本事，查得准是功力：常见问题与排查
4.1 明明写了注释却查不到
这是最让人头疼的情况。SQL写了、注释也写了，结果COMMENTS还是空，或者整条记录都不在。我归纳了几种典型原因：
| 可能原因 | 判断方法 | 解决办法 |
|---|---|---|
| 表确实没写注释 | 用SELECT * FROM USER_TAB_COMMENTS WHERE TABLE_NAME='XXX'，COMMENTS为NULL | 执行COMMENT ON TABLE ... IS '说明'补上 |
| 同名表出现在多个模式 | 用ALL_TAB_COMMENTS查OWNER，确认到底哪张表有注释 | 查询条件加上OWNER |
| 大小写问题 | 原来表名用了引号，存的是小写 | 用UPPER(TABLE_NAME)或按原大小写精确匹配 |
| 权限不足 | 有记录但被过滤，普通用户查不到系统表 | 改用USER_TAB_COMMENTS等视图 |
我建议排查时先切换到视图查询，如果视图能查到，说明系统表层面的问题基本不存在，多数是权限或过滤条件的问题。视图的可见范围就是当前用户当前权限下“应该能看到”的数据，用它做基准既方便又安全。
4.2 更新注释后看到旧值
有时候你执行了COMMENT ON TABLE EMPLOYEE IS '新注释'，紧接着去查SYSTABLECOMMENTS，结果还是旧值。第一反应不要怀疑SQL，先看事务有没有提交。达梦和Oracle一样，注释操作是在事务里生效的，客户端工具如果没开启自动提交，你就要手动执行COMMIT。
如果你用脚本批量更新注释，也建议在循环之后显式提交一次，别每执行一条就开一个事务，那样性能差。另外，如果是在存储过程里做的，注意过程内部提交点的位置，避免更新完注释却因为后面异常被整体回滚了。
4.3 普通用户访问权限的边界
SYS.SYSTABLECOMMENTS归属于系统模式，普通业务用户不一定有读权限。很多开发者在里面执行SELECT * FROM SYS.SYSTABLECOMMENTS时，被提示权限不足，这很正常。生产环境我也不建议你给一堆业务账号开放系统表权限，毕竟数据字典是全局性的东西。
正确的姿势是用兼容视图，比如你自己库里的表注释可以通过USER_TAB_COMMENTS查，跨模式用ALL_TAB_COMMENTS，管理员用DBA_TAB_COMMENTS。如果实在有特殊需求，才考虑由管理员执行：
GRANT SELECT ON SYS.SYSTABLECOMMENTS TO USER_X;这句话能不用就不用，尤其是生产库。权限开放越大，元数据被误读误写的风险就越高。
4.4 乱码：注释变成“????”
注释乱码的根子多半在字符集。写入注释时，客户端会话字符集和数据库字符集不一致，比如库是GBK，客户端却用了UTF-8，或者反过来。查出来的中文就会变成问号或乱码。
我建议你从三方面排查：第一步，确认数据库的字符集参数；第二步，确认客户端工具/驱动连接串里的编码配置；第三步，重新执行COMMENT ON语句覆盖一次。在JDBC连接串里显式指定字符集是个好习惯，不要依赖操作系统默认。已经乱码的数据，光靠改连接是救不回来的，必须重写注释。
4.5 千万别直接UPDATE系统表
系统表是数据库的“内政”。你可以读它、查它，但不要试图直接对它UPDATE或DELETE，哪怕你是管理员。系统表里的数据是数据库引擎在运行过程中维护的，手工改一行，轻则注释对象对不上，重则引发数据字典不一致，让数据库连启动都困难。
要修改注释，请老老实实用标准SQL：
COMMENT ON TABLE EMPLOYEE IS '员工信息表'; COMMENT ON COLUMN EMPLOYEE.SALARY IS '月薪';这就像改物业登记册，只能通过物业窗口办手续，你不能自己拿支笔去改登记册上的字。这条原则把它记住，能省掉很多灾难性故障。
4.6 从Oracle迁移过来的SQL怎么改
如果你之前写的是Oracle，迁到达梦后你会发现兼容性做得已经不错。以注释查询为例：
| 查询需求 | Oracle旧写法 | 达梦推荐写法 |
|---|---|---|
| 当前用户表注释 | USER_TAB_COMMENTS | USER_TAB_COMMENTS |
| 全库表注释 | DBA_TAB_COMMENTS | DBA_TAB_COMMENTS |
| 底层系统表 | 很少直接碰 | SYS.SYSTABLECOMMENTS |
多数SQL可以直接跑，因为视图名是兼容的。但如果你之前写的是Oracle极其内部的系统表，比如SYS.OBJ$之类，那到了达梦就必须改成达梦自己的系统表或兼容视图。我还是那句话：能用视图就别碰系统表，至少跨数据库迁移时你还能少改几行代码。
5. 一个实用习惯：把注释巡检融入日常维护
SYSTABLECOMMENTS不只能帮你一次性地查表注释，它还能成为一个持续的元数据质量抓手。我自己的习惯是，每个月跑一次全库注释完整性检查，逻辑很简单：
SELECT OWNER, TABLE_NAME, NVL(COMMENTS, '【缺少注释】') FROM ALL_TAB_COMMENTS WHERE TABLE_TYPE = 'TABLE' ORDER BY OWNER, TABLE_NAME;把查询结果导出，再和上个月导出的清单做对比，重点看两类变化：新增的表有没有注释；已有表的注释有没有被改动。这个动作不需要多复杂的工具，一个定时任务加文本比对就行。
我见过很多团队花大力气做各种数据标准文档，结果表一多，文档立刻过期。如果能把“注释”作为最轻量的元数据管理方式，让开发者在建表顺手写下COMMENT ON，数据字典的可用性会好很多。说白了，系统表只是工具，能不能用上它的价值，取决于你愿不愿意把注释当成一台数据库运行时的基本功。每次我接手一个旧库，第一件事就是查这一张系统表，花十分钟就能判断出这套环境的元数据管理水平。这一点，我觉得比任何花哨的治理平台都实在。
