★ FEATURED ARTICLE 接触 PostgreSQL 时间长了你会发现凡是值得调优、扒内核、做兼容迁移的活儿最后都会绕回到几张“关系”上pg_class、pg_attribute、pg_type、pg_namespace。这些表合在一起就是 PostgreSQL 的系统目录System Catalog也就是数据库自己的“字典”。我最早被这些表逼疯是在做跨版本数据迁移时需要把一张旧表的结构完整映射到新环境。用 IDE 看图拉字段能看个大概但自动生成 DDL 时总是差那么几列或者在客户端里能看到列默认值到了 SQL 里却不知道去哪里取。后来彻底读了一遍pg_class、pg_attribute相关的系统表文档才算是把元数据查询这件事打通了。这篇文章打算沿着一条实际能走通的路径来讲目录表的整体思路、核心表结构与字段含义、如何组合查询拿到建表字段信息、以及我在实际项目中踩过的坑。适合刚接触 PostgreSQL 但被元数据绕晕的开发者也适合想系统梳理 Postgres 内部结构的 DBA。如果你能跟着敲完示例 SQL再回去看任何 Postgres 管理工具的输出大概率不会再觉得它们是“黑魔法”了。1. 内容整体设计与思路拆解1.1 为什么 PostgreSQL 要维护一套系统目录表数据库要管理表、字段、索引、约束、权限还要把这些信息在崩溃恢复后完整找回来就必须有一套自描述的数据结构。PostgreSQL 的选择是把这些元数据也做成普通表挂在pg_catalogschema 下并且用 OIDObject Identifier在内部互相引用。你查询普通表时优化器要先走一遍pg_class、pg_attribute才能知道目标表有哪些可用的列能不能走索引行估算大概是多少。也就是说元数据表不是只在管理员去做\d时才被访问而是每一条 SQL 都可能触碰的基础设施。这也是为什么常见运维建议里总会提醒你别去手工 UPDATE 系统表——改坏了整个实例的 SQL 执行就可能直接异常。从设计意图上看PostgreSQL 选择将系统目录暴露为普通表而非独立私有格式是为了让管理逻辑尽可能统一备份、恢复、事务、MVCC、权限控制都能复用同一套机制。我们手工查元数据就是从一个用户视角“偷看”数据库内部对自己元数据的存储方式。理解这个设计你就明白为什么pg_attribute里有一行行的attnum而不是像某些数据库那样给一个固定 JSON 结构——PostgreSQL 需要实时、稳定、可并发访问的属性列表。1.2 系统目录的整体层级namespace → class → attribute → type如果给备忘录画个关系图我的理解是一条链先有pg_namespaceschema再在某个 schema 下建立pg_class表/索引/视图等然后在pg_class上挂pg_attribute列最后通过列的类型 OID 关联pg_type数据类型。映射到查询习惯上你会发现几乎所有元数据接口都围绕这表做 JOIN。例如一个 schema 下有哪几张表查pg_class.relnamespace pg_namespace.oid一张表有几列、每列什么类型查pg_class.oid pg_attribute.attrelid某个列是什么类型查pg_attribute.atttypid pg_type.oid列有没有默认值、能不能为空看pg_attribute.atthasdef、attnotnull在实际工作中我很少直接查pg_catalog文档中列出的几十个字段而是先锚定pg_class与pg_attribute。它们两个就像是目录表里的“主表”和“明细表”前者一行代表一个数据库对象后者多行描述该对象的属性集合。1.3 为什么不用 information_schema 直接查要回答这个问题可以先看information_schema.columns它确实把列名、数据类型、可空性、默认值都打包好了使用起来比直接查系统表友好很多。但它也有几个我后来才意识到的问题可移植性是标准化的结果但 PostgreSQL 特有细节比如attgenerated生成列、存储参数attstorage、列统计目标attstattarget在information_schema中不一定暴露或名称不直观。元数据查询往往要和pg_stat_all_tables、pg_index、pg_constraint等系统视图组合信息模式里这些关联比较薄弱。在排查死元组、膨胀、索引失效这类问题时最终还是要回到pg_class的reltuples、relpages、relfrozenxid等字段上。因此我自己的习惯是快速看字段定义用\d或information_schema.columns做深度排查、生成脚本、分析对象依赖时直接查pg_class、pg_attribute等系统目录表自由度完全不同。2. 核心细节解析与实操要点2.1 pg_class对象注册表的核心字段pg_class可能是整个 PostgreSQL 里信息量最大的一张目录表。它一行描述一个关系relation关系可以是普通表、索引、序列、视图、复合类型等等靠relkind区分。我日常最常用的字段如下字段作用使用场景oid对象唯一标识几乎所有其他目录表都通过它关联relfilenode后指向物理文件relname关系名查询的主体条件relnamespace所属 schema 的 OID与pg_namespace关联确定完整限定名relkind关系类型r普通表、i索引、S序列、v视图、m物化视图、c复合类型、p分区表reltuples优化器估算行数判断统计信息是否刷新、是否膨胀relpages占用的页数估算物理大小经常与reltuples一起看relfilenode物理文件节点名对线上问题排查、发现分区表与主表差距时很有用reltoastrelidTOAST 表的 OID行宽较大时出现判断是否需要优化存储relfrozenxid事务冻结界限排查 VACUUM 是否健康推进的参考项relhasindex是否建有索引快速排除无索引表的场景挑选字段时有一条经验oid你不能假设一定等于物理文件名因为TRUNCATE、VACUUM FULL、CLUSTER都可能让relfilenode变化。理解这一点后你才不至于在数据目录里按 OID 找文件时找错地方。另外relkind判断异常常用。比如你想列出普通表和分区表但分区的子表也出现在pg_class中如果不加relkind过滤统计结果很容易多算。有一次我在统计一批报表表数量时发现实际只有 40 张表程序却统计出 70 多个对象最后查出来是视图、序列、物化视图全被混进去了。加上relkind r之后数字立刻正确。pg_class还有一个容易忽视的点分区表的主表与子表都各有pg_class行。主表的relkind p子表通常也是r。查询时如果要过滤出用户可见表需要联合考虑relpersistencep临时表、u非日志表、空为普通表和relkind最稳妥的是加pg_catalog.pg_get_userbyid(relowner)过滤掉系统内置对象。2.2 pg_attribute列级定义的明细账拿到pg_class后下一步通常是看这个对象有哪些列。这就要查pg_attribute。它的核心字段我梳理如下字段含义注意点attrelid所属关系的 OIDJOIN 的关键attname列名直接可用但继承场景下多行同名会存在atttypid数据类型 OID关联pg_type才能得到类型名称attstattarget统计目标默认 -1表示继承全局默认值排查统计信息异常时看一眼attlen类型固定长度变长类型为-1这是内部行为不必过度解读attnum列序号1 开始系统隐含列为负值查询时建议过滤attnum 0attnotnullNOT NULL 约束标记直接看到是否可为空atthasdef是否有默认值表达式默认表达式内容不在本表在pg_attrdefattisdropped是否已被 DROP已删除列的残骸必须过滤否则会出现幽灵列attgenerated生成列标记空为普通列s为存储生成列v为虚拟生成列attidentity标识列标记a为 alwaysd为 by defaultattcollation排序规则 OID通常在处理中文排序时才会用到我集中踩过的坑有两个。第一不要忘记attisdropped。执行ALTER TABLE DROP COLUMN之后PostgreSQL 并不会真正立刻擦除列定义而是把这列标记为attisdropped true。如果查询时不过滤attisdropped你会在结果里看到很多名为........pg.dropped.1........的残列数量跟历史删除次数有关。刚接触系统表的人会非常困惑表结构里明明没有这些列怎么系统表里一大堆所以查询列信息的最低标准是WHERE attnum 0 AND NOT attisdropped第二attnotnull不等于约束完整信息。它只能表达“列定义为 NOT NULL”但CHECK约束、外键约束、唯一约束都在pg_constraint表里。如果你想生成完整的建表语句光是attnotnull远远不够必须继续查pg_constraint和pg_index。理解这一点能避免你写完导表工具后发现目标库丢了一堆约束。attgenerated是 PostgreSQL 12 之后比较重要的字段。如果你在 11 及以下版本做兼容性开发这个字段是不存在的写查询时最好做版本分支判断。如果直接SELECT attgenerated查老版本会直接报错这一点需要在脚本里留意。2.3 pg_type数据类型的翻译官很多新手会直接看atttypid发现是一串 OID 数字完全不知道对应什么类型。其实pg_type就是负责把这串数字翻译成integer、text、timestamp等名称的表。pg_type重要的字段typname类型名typnamespace类型所属 schema 的 OIDtyptype类型分类。b是基本类型c是复合类型d是域e是枚举r是 rangem是 multirangep是伪类型typcategory类型功能分组比如A是数组类型、S是字符串类型、N是数值类型、T是时间类型typrelid如果它是复合类型这里指向pg_class的一行typelem数组类型的元素类型做类型转换时你常会看到类型名带[]比如text[]。系统目录里实际是数组类型对象它本身的typname叫_texttypelem指向text。查询时直接JOIN pg_type ON atttypid ty.oid拿到的是_text如果转换成人类可读的text[]直接用format_type(atttypid, atttypmod)最省事。另外pg_type里存在多个同名类型比如每张表都会自动生成一个复合类型类型名和表名相同。如果JOIN时只看typname容易混淆。所以要同时带上typnamespace并按typtype分析比如typtype c的复合类型常常由表中行结构生成。2.4 关联查询时最容易漏的内外连接细节关系表只是把数据存储在那里它不会告诉你哪些字段组合是业务意义上的“完整”。用JOIN组装元数据时最常见的问题是为什么某张表明明有数据列数量却少了我的经验是查列信息时必须以pg_attribute作为驱动表再左连接pg_type。因为pg_attribute是全量字段表而pg_type理论上都会对得上。但如果反过来以pg_type驱动会出现大量无关类型让结果牛头不对马嘴。另一个隐蔽问题pg_attribute的行数可能因为继承关系而包含父表的列。PostgreSQL 的表继承和分区表会在子表的pg_attribute中出现父表列。查询时如果你只拿到一张子表却不带attinhcount过滤你看到的列会比你想象中的多。对普通表继承场景通常查询条件要加上WHERE attinhcount 0这句的意思是只显示子表自身定义的列不展示从父表继承来的列。但从分区表查询时分区子表继承的列和分区主表的列其实是同一套定义如果你想看到完整结构不一定要过滤attinhcount。实际取舍要看场景。3. 实操过程与核心环节实现3.1 从零开始查询schema 下的所有表清单第一条实用 SQL我建议先拿它练手。列出某个 schema 下的所有普通表、分区表忽略索引、视图、序列、外部表。SELECT n.nspname AS schema_name, c.relname AS table_name, c.relkind, c.oid, c.reltuples::bigint AS estimated_rows, c.relpages, pg_size_pretty(pg_total_relation_size(c.oid)) AS total_size FROM pg_class c JOIN pg_namespace n ON n.oid c.relnamespace WHERE n.nspname public AND c.relkind IN (r, p) ORDER BY c.relname;这里我特意不查c.relowner直接显示用户名而是留给需要时再关联因为日常管理通常只关心物理结构。如果查询时发现reltuples是-1说明该表 ANALYZE 还没跑过或者最近改动太大导致统计信息缺失不是数据真的为负。3.2 查询表的完整列信息类 psql \d 的自定义实现如果要在代码里模拟\d table效果可以像下面这样查。这是我最常用的“万能列信息查询”SELECT a.attnum, a.attname, format_type(a.atttypid, a.atttypmod) AS data_type, a.attnotnull AS not_null, pg_get_expr(d.adbin, d.adrelid) AS default_expr, a.attidentity AS identity, a.attgenerated AS generated, a.attstattarget AS stats_target, col_description(a.attrelid, a.attnum) AS comment FROM pg_attribute a LEFT JOIN pg_attrdef d ON d.adrelid a.attrelid AND d.adnum a.attnum WHERE a.attrelid public.my_table::regclass AND a.attnum 0 AND NOT a.attisdropped ORDER BY a.attnum;注意几个细节public.my_table::regclass会把字符串自动转换成 OID。如果对象不存在会直接报错便于尽早发现问题。format_type()函数会考虑类型长度修饰符比如varchar(255)不会只显示成varchar。pg_get_expr(d.adbin, d.adrelid)用于把默认值表达式从内部结构解析成可读文本。如果不是 expression直接从pg_attrdef的原始字节里读别人看不懂。列注释不在pg_attribute表里需要通过col_description()函数获取内部查询的是pg_description表。手上的项目里我用这条 SQL 自动生成“数据结构比对报告”把源库和目标库的列定义分别查出来之后做 diff。实践下来比直接读pg_dump输出更可控因为可以只选需要比对的列。3.3 查询列的注释与权限信息假如你要同步一份表结构文档光有列名和类型不够。注释信息就是在这个环节查的。SELECT c.relname AS table_name, a.attname AS column_name, col_description(a.attrelid, a.attnum) AS column_comment, obj_description(c.oid, pg_class) AS table_comment FROM pg_class c JOIN pg_attribute a ON a.attrelid c.oid WHERE c.oid public.my_table::regclass AND a.attnum 0 AND NOT a.attisdropped ORDER BY a.attnum;权限信息则要查pg_class.relacl与列级pg_attribute.attacl。attacl是 AclItem 数组直接看比较晦涩通常用aclexplode()函数展开才能得到“哪个角色对哪列有哪些权限”。做列级权限审计时这条 SQL 非常实用SELECT a.attname AS column_name, grantor.rolname AS grantor, grantee.rolname AS grantee, privs.privilege_type FROM pg_attribute a CROSS JOIN LATERAL aclexplode(a.attacl) AS privs LEFT JOIN pg_roles grantor ON grantor.oid privs.grantor LEFT JOIN pg_roles grantee ON grantee.oid privs.grantee WHERE a.attrelid public.my_table::regclass AND a.attnum 0 AND NOT a.attisdropped;如果不了解acl的默认值可能以为attacl是空的就代表没有权限。但实际上空值表示“使用表级默认权限”并不是没权限。理解这一层之后才能在权限审计时避免误报。3.4 借用系统函数包装成“即拿即用”的工具PostgreSQL 内置了一批元数据函数能省掉很多手写 JOIN。它们本质上是帮你把系统表查询包装成了函数。函数作用pg_get_tabledef(regclass)高版本中可直接生成表定义 DDLpg_get_functiondef(oid)返回函数定义pg_get_indexdef(index_oid)解析索引定义pg_get_viewdef(view_oid)解析视图定义pg_get_constraintdef(oid)生成约束定义pg_get_userbyid(oid)将角色 OID 翻译成名称format_type(oid, typmod)人类可读类型to_regclass(text)字符串转 regclass不存在返回 NULLpg_get_tabledef是相对新的函数早版本只能用pg_dump或手工拼接。生产环境如果版本支持强烈建议先试一试。我自己在给客户做“不停机转换”前的结构快照时经常直接用pg_get_tabledef输出 DDL作为备份基线。这类函数和直接查目录表的区别在于函数返回的已经是后端格式化后的文本不需要你再去拼接逗号、括号、缩进。但函数不可移植且在高并发调用时可能放大服务端工作量不适合做成高频查询。3.5 识别“正常表”与“系统表”有时你只想看到用户自己创建的表而不是有几十张系统表混在一起。判断方法有几种过滤c.relnamespace排除pg_catalog和information_schema过滤c.relkind r只留普通表过滤掉c.relpersistence t的临时表判断是否用户表c.relowner不是pg_catalog初始超级用户但有的时候业务也用自己的超级用户建表所以不绝对最实用的做法是先查所有 schema 名称SELECT nspname FROM pg_namespace WHERE nspname NOT LIKE pg_% AND nspname information_schema;pg_namespace中pg_*开头通常是系统内置 schema用户 schema 很难用pg_前缀命名。这个方法在写审计脚本时很常用。4. 常见问题与排查技巧实录4.1 为什么 reltuples 和 COUNT(*) 差别巨大这是查pg_class时最经典的疑惑。reltuples只是优化器统计信息里的估算值COUNT(*)是全表实时扫描结果。两者不一致不是 bug是设计和性能的妥协。原因链条是这样的ANALYZE默认采样一部分页面然后根据样本比例推算全表行数表在ANALYZE之后继续写入、更新、删除reltuples并不会同步更新。死元组也会被纳入统计这会让估算值进一步偏离真实值。如果某张表经常被大量更新然后你把它从pg_class查出来看行数经常能对不上。可用方案对目标表执行ANALYZE table_name;后重新查询。执行VACUUM table_name;它会刷新一部分统计但不一定会完全对齐取决于版本策略。直接跑COUNT(*)时如果是大表要有心理准备它会做全表扫描。我自己在做运维巡检时不会只看reltuples就下结论而是结合n_live_tup来自pg_stat_user_tables对照。正常情况下两者的差能反映统计信息新鲜度。如果n_live_tup与reltuples长期严重偏离说明autovacuum可能没跑起来或者表过于庞大导致采样不准。4.2 pg_attribute 中出现了“幽灵列”怎么办前面提过attisdropped这里再展开一次。出现幽灵列的场景通常包括ALTER TABLE t DROP COLUMN old_col;此时pg_attribute并不会物理删除这一行而是设置attname ........pg.dropped.1........attisdropped trueattnum保持原位置不变如果新加列为了保持列顺序PostgreSQL 可能继续使用这个已经被标记删除的attnum。如果你在生成代码时不加过滤条件等于是把一段历史的“尸体”当成了活动列输出结果必然错位。排查方式非常简单SELECT attnum, attname, attisdropped FROM pg_attribute WHERE attrelid public.t::regclass ORDER BY attnum;如果发现大量attisdropped true说明这张表历史上做过多次字段删除但这不是性能问题只是元数据层面的一种“保留历史”策略。对于需要精确导出结构的需求必须在每一处查询列信息的 SQL 中统一加过滤条件。4.3 如何排查“表膨胀”与“列缺失”同时出现的问题我遇到过一个真实场景某张业务表近一个月频繁 DROP 字段、ADD 字段结果系统表pg_attribute里残留了大量删除列而实际数据文件里也存在大量死元组。表现为查询pg_attribute时列很多。但 SELECT 能看到的活动列没那么多。pg_stat_user_tables中n_dead_tup持续高位。当时我排查分为三步先确认活动列数量与实际列数量差了多少。再查pg_attribute中attisdropped总量确认是否因频繁 DDL 导致。查pg_stat_user_tables的死元组判断是否长时间未 VACUUM。如果死元组一直不降且表很大我会先跑VACUUM (VERBOSE) public.my_table;如果 VACUUM 之后仍然膨胀严重再考虑VACUUM FULL但要用业务低峰期。需要注意的是频繁 DDL 不会直接造成表数据膨胀但每执行一次ALTER TABLE DROP COLUMN都可能产生触发器和依赖解析开销加上默认DROP COLUMN的行为只是标记并不会立即释放空间所以大表的字段删减一定要谨慎。这里给一个经验值连续几十次 DROP ADD 列之后pg_attribute的行数膨胀不可怕真正可怕的是整个 TOAST 表、索引和约束的重建代价。设计表结构时最好一次性规划好列而不是把生产表当临时草稿纸。4.4 查询元数据慢、卡、占用高怎么办pg_catalog表里的行数通常不会特别大就算是大型实例也不会膨胀到千万级除非有人真的乱 UPDADE 系统表。所以元数据查询变慢通常不是因为表本身太大而是因为查询方式没走索引或 JOIN 了过多大数据视图。以下几种情况值得注意在pg_stat_user_tables里拿快照但这条视图会实时统计每个表的 I/O 状况频繁调用会拉长响应时间。直接把pg_attribute与pg_class、pg_type、pg_constraint、pg_index全连起来生成“万金油”查询然后每一次都要扫描多张系统表。使用WHERE relname tablename时没注意同名对象存在于不同 schema虽然最终能返回但优化器可能需要遍历不少候选行。优化方向用::regclass尽量先锚定 OID。只查需要的系统表别一上来就 JOIN 七八张。查统计信息时尽量从pg_stat_user_tables取一次性的快照而不是反复统计。对低频管理类 SQL可以在维护窗口执行避免和业务流量叠加在一起。我见过有人在pg_attribute表上做COUNT(*)其实本来数据量就不大但并发频繁执行也造成了轻微锁竞争。元数据是共享资源所有后端的优化器都可能访问所以管理脚本不要设计成高频轮询。4.5 表名、列名大小写问题的元数据表现PostgreSQL 对于未加引号的标识符会折叠成小写存储。这个机制的副作用是你在pg_class里看到的名字可能与你在客户端输入的 SQL 不完全一致。最典型的情况CREATE TABLE MyTable (id INT);写死的MyTable在系统表里实际存为mytable。如果不使用双引号后续查询MyTable也指向小写版本。但如果你执行CREATE TABLE MyTable (id INT);系统表里存的就是MyTable。这两种情况下你在pg_class查询时如果WHERE relname mytable只能查出第一种查第二种条件要写成relname MyTable。为了避免踩坑脚本里统一建议WHERE c.oid to_regclass(public.MyTable)to_regclass会遵循 PostgreSQL 的标识符解析规则把大小写、schema 限定都能正确处理。如果直接拼字符串去匹配relname碰到带引号的表名很容易漏数据。4.6 表结构变更后能否回滚但凡用ALTER TABLE动过结构系统表里留下的旧结构痕迹就说明一切。虽然在事务中包裹 DDL 可以回滚但一旦提交目录表的旧行并不会自动恢复。所以如果你经常要在测试环境反复调整表结构建议保留一份“结构基线 SQL”。我自己的习惯是在交付表结构之前用pg_dump --schema-only做一次备份或者把上面的“完整列信息查询”结果存成哈希快照。这样即使后续改出问题也能快速对照系统表里的现状排查是哪一次变更引入的问题。从另一个角度说因为系统目录表遵循事务机制所以你在一个事务块里执行CREATE TABLE后在没提交前偷偷查pg_class也能看到该表。这一点和普通 DML 行为一致。很多自动化测试利用这个特性来做“临时表”管理但注意不要依赖它做复杂逻辑毕竟并发场景下目录表的可见性同样受 MVCC 约束。5. 进阶经验从元数据构建自己的管理工具箱5.1 自动生成“列结构对比报告”我在做数据库版本升级兼容性检查时会对比两个实例上的同一张表结构是否一致。用系统表写一个“结构指纹”查询把列名、类型、可空、默认值、注释拼成一个文本然后做 MD5 比对。SELECT md5(string_agg(line, | ORDER BY attnum)) AS fingerprint FROM ( SELECT a.attnum, format(%s:%s:%s:%s:%s, a.attname, format_type(a.atttypid, a.atttypmod), a.attnotnull, COALESCE(pg_get_expr(d.adbin, d.adrelid), ), COALESRE(out one line) ) AS line FROM pg_attribute a LEFT JOIN pg_attrdef d ON d.adrelid a.attrelid AND d.adnum a.attnum WHERE a.attrelid public.my_table::regclass AND a.attnum 0 AND NOT a.attisdropped ) t;两个环境都跑同一段 SQL比对fingerprint就能快速定位结构差异。这样做比肉眼 review DDL 快得多尤其表数量多的时候。5.2 借助pg_depend分析对象依赖有时候你删一张表数据库报错提示有依赖对象但错误信息不够完整。这时候可以查pg_depend和pg_rewrite。pg_depend记录对象之间的依赖关系。常用组合是视图pg_class依赖基础表带有默认值的序列依赖表中列物化视图依赖源表外键约束依赖被参照表我查依赖的 SQL 大致长这样SELECT src.relname AS dependent_object, dst.relname AS referenced_object FROM pg_depend d JOIN pg_class src ON src.oid d.objid JOIN pg_class dst ON dst.oid d.refobjid WHERE d.refobjid public.my_table::regclass AND d.deptype ndeptype n是普通依赖删除被引用对象时会带上它们。如果只想找视图、外键这类对象再关联pg_rewrite或pg_constraint即可。这个查询在做数据清理、删表前评估影响面时特别有用。5.3 批量生成动态 SQL 的注意事项元数据查询常被用于批量生成VACUUM、ANALYZE、GRANT、甚至COPY语句。这时你需要用到quote_ident()或者format(%I)把对象名安全拼接。否则表名或列名里带空格、大小写、特殊字符时直接拼到 SQL 里会报错或注入风险。例如批量对用户表执行 ANALYZESELECT format(ANALYZE %I.%I;, n.nspname, c.relname) AS stmt FROM pg_class c JOIN pg_namespace n ON n.oid c.relnamespace WHERE c.relkind r AND n.nspname NOT LIKE pg_% AND n.nspname information_schema;拿到stmt后在管理端执行。这种方式适合一次性运维脚本能避免手工打几百条同类型 SQL。缺点是无法利用DO块直接执行但配合程序语言或 psql 元命令已经足够。5.4 元数据缓存为什么第一次查询慢后续变快PostgreSQL 有系统目录缓存syscache第一次查询pg_class后常见对象会被缓存后续同类查询会走缓存路径。所以这带来一个隐形问题你在一条长事务里修改了系统目录但同事务后续通过缓存读取到旧版本的数据这可能导致奇怪的结果。例如你在事务中CREATE TABLE然后立刻去SELECT * FROM pg_class WHERE relname new_table大多数情况下能看到但如果你依赖缓存且语句复杂可能遇到“看不到刚建对象”的错觉。这种情况在小版本或特殊并发下偶发。最佳实践是自动化脚本不要在一个事务里同时做DDL和复杂的元数据依赖检查要么提交后再查要么用独立的会话。实际运维中我倾向于让 CICD 脚本先执行 DDL提交后再执行元数据检查。这样能规避缓存和可见性问题也能避免一个失败步骤回滚整个结构变更。最后再聊点我的个人体会系统目录表能不能玩得转很大程度上取决于你对“OID 关联”这个概念的理解深度。不要死记硬背字段只要记住几条主链路查 namespacepg_namespace查对象pg_class查列pg_attribute查类型pg_type查默认值pg_attrdef查约束pg_constraint查索引pg_index所有的元数据查询都是围绕这些表的 OID 做 JOIN 展开。你真正常用的其实没有几十张表核心就这些。还有一个经验尽量用 PostgreSQL 提供的元数据函数比如format_type()、pg_get_expr()、col_description()。因为系统表里很多字段是内部存储格式直接裸读看起来像天书比如默认值的pg_node_tree结构没有函数解析根本没法读。把这些函数用熟你写出的元数据查询可读性会提升一大截。最后提一个建议如果要在生产环境反复执行元数据查询请加上注释、放在单独事务里、设置合理的statement_timeout。系统目录表本身不大但无节制的笛卡尔 JOIN 或者把pg_stat_*视图和pg_class连在一起使用也一样能把数据库服务器拖得很难看。内核给我们打开了窥视内部结构的窗口但也要用对姿势才不会在凌晨的 on-call 电话里追悔莫及。
阅读完成 · 觉得有帮助？
