数据库表字段信息查询全攻略：主流数据库通用手册-北京尧图网络

查询数据库表字段信息一篇能直接抄作业的全库通用手册干这行这么多年被问得最多的问题之一就是“我这张表里都有哪些字段”。新人问偶尔一些写了好几年业务代码的老哥也会愣一下——尤其是刚从 MySQL 切到 Oracle或者从 SQL Server 跳到 PostgreSQL 的时候查询字段信息的方式说变就变很让人头大。其实这东西不难难的是你不知道去翻哪个系统表、哪张视图。今天我把主流数据库的字段查询方法一次性整理出来附带我在实际项目中踩过的坑和验证过的写法保证你读完就能直接用不用再去搜索引擎里翻半天。这篇内容适合所有跟数据库打交道的人日常写 SQL 的分析师、维护老系统的开发、做数据迁移的 DBA甚至刚上完数据库课程正在做课程设计的学生。看完你会明白不同数据库查字段信息的方式虽然长得不一样底层逻辑其实惊人地一致一通百通。1. 查询字段信息背后的核心思路1.1 字段信息到底是指什么在动手写 SQL 之前先把概念捋清楚。所谓“字段信息”不只包含字段名完整的一套应该包括以下内容字段名column_name数据类型data_type是否允许为空is_nullable默认值column_default / data_default是否主键primary key字符集和排序规则针对字符串类型字段注释/备注column_comment字段顺序ordinal_position平时咱们查字段80% 的场景其实只需要前面几项。但在做数据字典整理、接口文档生成、ETL 抽取逻辑编写的时候这些信息一个都不能少。所以查字段的核心其实就是查数据库的“元数据”——也叫数据的数据。1.2 为什么不同数据库查法差这么多用 MySQL 的人习惯了DESC table_name一下就把结构全列出来换成 Oracle 就得写一长串关联查询心里难免不爽。但你要理解背后的原因MySQL 和 SQL Server 遵循 SQL 标准提供了information_schema这个系统库里面把元数据统一做了规范化而 Oracle 呢它有一套自己的数据字典视图如ALL_TAB_COLUMNS虽然也兼容一部分标准但写法完全不同。PostgreSQL 呢它夹在中间既有information_schema又有自己的pg_catalog系统表性能要求高的时候你恨不得直接查pg_attribute。这些差异本质上是各数据库厂商在架构决策上的分歧——有的更重视标准兼容有的更重视查询性能有的历史包袱重只能在一个老系统上不断打补丁。理解了这一点后面看到什么奇怪的写法都不会觉得难记了。1.3 通用的查询“地图”不管什么数据库核心都是先定位“放字段信息的那张系统表或视图”然后用字段名过滤即可。你可以把整个思路画成这样一张地图我文字描述给你好记information_schema系列MySQL、PostgreSQL、SQL Server、达梦数据库的兼容模式都会提供数据字典视图系列Oracle 的ALL_TAB_COLUMNS、USER_TAB_COLUMNS、DBA_TAB_COLUMNS系统表直查系列PostgreSQL 的pg_attribute、SQL Server 的sys.columns、SQLite 的PRAGMA table_info()先把这张地图印在脑子里下文每个数据库的具体写法都是这张地图上某个节点展开的细节。2. 主流数据库字段信息查询实操2.1 MySQL最简单但别只会用 DESC先把 MySQL 说了因为用的人最多。最粗暴直接的写法DESC your_table_name;或者SHOW FULL COLUMNS FROM your_table_name;这两条命令的结果SHOW FULL COLUMNS比DESC多了 collation、privileges、comment 这些列日常开发中我更推荐用这条尤其是写接口文档时要拎字段注释一次就能拿全。如果是在程序里动态拼 SQL或者要做条件筛选那就得走information_schema了SELECT COLUMN_NAME AS field_name, COLUMN_TYPE AS data_type, IS_NULLABLE AS nullable, COLUMN_DEFAULT AS default_value, COLUMN_COMMENT AS comment, ORDINAL_POSITION AS position FROM information_schema.COLUMNS WHERE TABLE_SCHEMA your_database_name AND TABLE_NAME your_table_name ORDER BY ORDINAL_POSITION;这里有个很重要的细节TABLE_SCHEMA这个条件一定得写不写的话如果你的 MySQL 实例上有多个库存在相同表名结果会混在一起非常容易闹出查错表结构的乌龙。顺便提一句想连主键信息一起查出来的话SELECT c.COLUMN_NAME, c.DATA_TYPE, c.IS_NULLABLE, c.COLUMN_DEFAULT, IFNULL(k.COLUMN_NAME, ) AS pk_flag FROM information_schema.COLUMNS c LEFT JOIN information_schema.KEY_COLUMN_USAGE k ON c.TABLE_SCHEMA k.TABLE_SCHEMA AND c.TABLE_NAME k.TABLE_NAME AND c.COLUMN_NAME k.COLUMN_NAME AND k.CONSTRAINT_NAME PRIMARY WHERE c.TABLE_SCHEMA your_database_name AND c.TABLE_NAME your_table_name ORDER BY c.ORDINAL_POSITION;这条 SQL 我经常在生成数据字典脚本的时候用一次性能把所有列的主键标记带出来省得再去翻第二张表。2.2 Oracle数据字典视图才是主力Oracle 的新手常常栽在一个地方用DESC确实能看到字段列表但信息太有限了而且拿不到注释拿不到默认值拿不到是否主键。真要干正事必须查数据字典视图。最常用的视图有三个层级USER_TAB_COLUMNS当前用户拥有的表ALL_TAB_COLUMNS当前用户能访问的所有表DBA_TAB_COLUMNS整个数据库所有表需要 DBA 权限实操中如果你只是想看自己能访问的表的字段用ALL_TAB_COLUMNS就够。示例SELECT COLUMN_NAME, DATA_TYPE, DATA_LENGTH, NULLABLE, DATA_DEFAULT FROM ALL_TAB_COLUMNS WHERE OWNER YOUR_SCHEMA AND TABLE_NAME YOUR_TABLE ORDER BY COLUMN_ID;如果你需要把字段注释一起查出来那必须额外关联ALL_COL_COMMENTSSELECT tc.COLUMN_NAME, tc.DATA_TYPE, tc.DATA_LENGTH, tc.NULLABLE, tc.DATA_DEFAULT, cc.COMMENTS AS column_comment FROM ALL_TAB_COLUMNS tc LEFT JOIN ALL_COL_COMMENTS cc ON tc.OWNER cc.OWNER AND tc.TABLE_NAME cc.TABLE_NAME AND tc.COLUMN_NAME cc.COLUMN_NAME WHERE tc.OWNER YOUR_SCHEMA AND tc.TABLE_NAME YOUR_TABLE ORDER BY tc.COLUMN_ID;在这里我提醒一句Oracle 的DATA_DEFAULT字段查出来是 LONG 类型如果你在 JDBC 里直接读取有时候会有兼容性问题。建议应用层把这一列单独处理或者转成 CLOB 后再读。另外一个坑是 Oracle 默认把表名、字段名存成大写如果你建表时用了双引号小写那查询条件里的大小写必须跟建表时完全一致否则查不到。2.3 PostgreSQL标准视图和系统表怎么选PostgreSQL 比较特殊它有两条路可以走。第一条标准路线查information_schema.COLUMNS写法跟 MySQL 几乎一样SELECT COLUMN_NAME, DATA_TYPE, IS_NULLABLE, COLUMN_DEFAULT FROM information_schema.COLUMNS WHERE TABLE_SCHEMA public AND TABLE_NAME your_table ORDER BY ORDINAL_POSITION;第二条性能路线直接查系统表pg_catalog。information_schema在 PostgreSQL 里本质是一组视图底层就是查这些系统表所以数据量大的时候直接查底层反而更快。你要拿到更丰富的内部信息比如字段的物理存储位置、统计信息就得用系统表SELECT a.attname AS column_name, format_type(a.atttypid, a.atttypmod) AS data_type, NOT a.attnotnull AS nullable, pg_get_expr(ad.adbin, ad.adrelid) AS default_value FROM pg_attribute a LEFT JOIN pg_attrdef ad ON a.attrelid ad.adrelid AND a.attnum ad.adnum WHERE a.attrelid your_schema.your_table::regclass AND a.attnum 0 AND NOT a.attisdropped ORDER BY a.attnum;这里的attnum 0和attisdropped false两个条件非常关键不加的话你会把系统隐藏列和已删除列也捞出来结果很脏。用::regclass直接把表名转成内部对象 ID 也是 PG 特有的优雅写法省去一次子查询关联。2.4 SQL Server系统视图组合拳SQL Server 我推荐直接走系统视图比information_schema好用多了。核心三件套是sys.tables、sys.columns、sys.types再配合扩展属性拿注释SELECT c.name AS column_name, t.name AS data_type, c.max_length, c.is_nullable, c.is_identity, CAST(ep.value AS NVARCHAR(500)) AS column_comment FROM sys.columns c INNER JOIN sys.types t ON c.user_type_id t.user_type_id LEFT JOIN sys.extended_properties ep ON ep.major_id c.object_id AND ep.minor_id c.column_id AND ep.name MS_Description WHERE c.object_id OBJECT_ID(dbo.your_table) ORDER BY c.column_id;注意一下SQL Server 的max_length对于 varchar/nvarchar 返回的是字节数不是字符数。varchar(50)显示 50nvarchar(50)显示 100因为一个字符占两个字节换算的时候别粗心搞错。一个比较实用的进阶玩法是动态生成修改字段注释的 SQL这样就可以批量给老表补注释SELECT EXEC sys.sp_addextendedproperty nameNMS_Description, valueN待补充, level0typeNSCHEMA, level0nameNdbo, level1typeNTABLE, level1nameNyour_table, level2typeNCOLUMN, level2nameN c.name FROM sys.columns c WHERE c.object_id OBJECT_ID(dbo.your_table) AND c.column_id NOT IN ( SELECT ep.minor_id FROM sys.extended_properties ep WHERE ep.major_id c.object_id AND ep.name MS_Description );这个思路的核心是让数据库替我们生成 SQL而不是手动一条条写业务表有上百个字段时效率差距巨大。2.5 SQLite / 达梦轻量级数据库也有自己的姿势SQLite 比较特殊它没有information_schema那种完整的元数据视图它用的是PRAGMAPRAGMA table_info(your_table);这个命令会返回字段序号、字段名、类型、非空约束、默认值和主键序号简洁够用。如果你想拿到字段注释SQLite 官方方案里注释不存储在 schema 里建议建表时就用COMMENT ON COLUMN新版 SQLite 支持或者单独建一张注释表维护。达梦数据库对 Oracle 兼容得比较好用法基本可以直接平移 Oracle 的写法不过要注意达梦还提供了一个SYSOBJECTS系统表体系。如果你是达梦新手先走ALL_TAB_COLUMNS路线最稳妥。3. 跨库通用方案一次写到处跑3.1 JDBC 的 DatabaseMetaData如果你的项目用 Java 开发不管底层是什么数据库java.sql.DatabaseMetaData都提供了一个统一的入口不用自己写各种方言 SQLConnection conn DriverManager.getConnection(url, user, password); DatabaseMetaData metaData conn.getMetaData(); try (ResultSet rs metaData.getColumns(null, schema, tableName, %)) { while (rs.next()) { String columnName rs.getString(COLUMN_NAME); String dataType rs.getString(TYPE_NAME); int size rs.getInt(COLUMN_SIZE); String remarks rs.getString(REMARKS); String isNullable rs.getString(IS_NULLABLE); System.out.printf(%-30s %-20s %-10s %-20s %s%n, columnName, dataType, size, remarks, isNullable); } }这段代码里的getColumns方法JDBC 驱动底层已经帮你翻译成对应数据库的原生查询了MyBatis Plus 的代码生成器、Flyway 的元数据比对走的都是这套 API。我自己写数据字典工具时基本都是用这个方法因为数据库一换上层代码一行不用动。3.2 脚本化方案Python 一网打尽偶尔要快速对一批表生成信息清单用 Python 也很舒服。以 MySQL 为例import pymysql conn pymysql.connect(hostlocalhost, userroot, passwordpass, databaseyour_db) cursor conn.cursor() sql SELECT COLUMN_NAME, COLUMN_TYPE, IS_NULLABLE, COLUMN_DEFAULT, COLUMN_COMMENT FROM information_schema.COLUMNS WHERE TABLE_SCHEMA %s AND TABLE_NAME %s ORDER BY ORDINAL_POSITION cursor.execute(sql, (your_db, your_table)) for row in cursor.fetchall(): print(row)这里的参数化查询是必须养成的习惯表名、库名凡是来自外部输入的一律不能直接拼进 SQL。虽然查元数据不像操作业务数据那样高风险但安全习惯在哪个环节都不能松。3.3 可视化工具怎么做最快日常巡检或者临时看结构根本不值得写 SQL。DataGrip、Navicat、DBeaver 都有图形化功能点开表节点就能看到字段列表、类型、注释、索引、外键一目了然。但注意可视化工具最终执行的本体还是我们上面写的那些 SQL。我在 DataGrip 里通过 console 看到它跑的是SELECT * FROM information_schema.COLUMNS WHERE TABLE_SCHEMA xxx AND TABLE_NAME yyy这就说明掌握原生 SQL 永远不会过时工具只是帮你包了一层。4. 实际业务场景中的进阶查询玩法4.1 数据字典一键导出我参加过不少项目交付阶段都要出数据字典文档。以前手工复制粘贴几百张表能让人崩溃。后来我写了一个存储过程直接把整个 schema 的字段信息导出成 INSERT 语句再灌进一张专用的字典表配合导出工具就能秒出文档。MySQL 核心逻辑SELECT TABLE_NAME, COLUMN_NAME, COLUMN_TYPE, IS_NULLABLE, COLUMN_DEFAULT, COLUMN_COMMENT FROM information_schema.COLUMNS WHERE TABLE_SCHEMA your_database ORDER BY TABLE_NAME, ORDINAL_POSITION;导出后在 Excel 里做透视表就能得到按表分组的完整字典。4.2 表结构变更影响分析老系统牵一发动全身改字段前必须先摸清楚哪些程序在用它。靠人肉搜索代码效率太低了先查字段在库里的基本信息类型、长度、默认值再去代码仓库里搜字段名基本可以精准定位受影响面。还有一个思路如果数据库开启了 binlog 或者审计日志可以在日志里搜索字段名找出真实访问过这些字段的 SQL 语句这个我在迁移老系统时用过效果特别好。4.3 自动化测试断言辅助有些自动化测试需要断言接口返回值比较规范的团队会先核对数据库表结构确认字段名一致性。比如前端传了个userName后端字段叫user_name接口层做了映射还没问题一旦没做映射查一下字段信息就能快速定位问题根源。这种问题在项目交付后维护期特别常见我排查过多次十有八九就是联调时没核对表字段信息。4.4 代码生成器的基础数据源现在的低代码平台、代码生成器底层都要拿字段清单来生成实体类、Mapper、DTO。我们自己做的一个内部小工具就是直接用information_schema查出字段名和类型再映射成 Java 类型然后套用 FreeMarker 模板一次性生成增删改查代码。字段信息查得准不准直接决定了代码生成器靠不靠谱。类型映射那步特别要注意不同类型数据库之间的细微差异比如 MySQL 的tinyint(1)该不该映射成 BooleanOracle 的Number精度不同该怎么处理这些经验都是在一次次踩坑中攒下来的。5. 常见问题与排查技巧实录5.1 大小写导致查不到字段这是我遇到的最频繁的问题。Oracle 默认大写PostgreSQL 默认小写MySQL 在 Linux 上区分表名大小写、字段名不区分SQL Server 的排序规则决定大小写是否敏感。排查思路很简单先执行一条最简单的查询比如只查COLUMN_NAME不带任何条件确认有没有数据有数据再逐步加条件看卡在哪一个条件上。然后在查询里加上UPPER()或者LOWER()函数做规范化。5.2 权限不足看不到元数据查到一半报ORA-00942: table or view does not exist或者 MySQL 下返回空结果集十有八九是元数据视图权限不够。MySQL 的information_schema对普通用户只展示自己有权限的对象Oracle 的DBA_TAB_COLUMNS需要特殊权限普通账号只能查ALL_TAB_COLUMNS。解决方案不是去硬造权限而是换一个当前用户权限范围内的视图来查或者找 DBA 开通只读权限。5.3 字段注释为空或乱码注释乱码最常见的原因是客户端字符集和数据库字符集不一致连接字符串里没加characterEncodingutf8MySQL或者utf-8Oracle 新版之类的参数。如果注释本身就没写入那无论怎么调编码都查不出来只能补齐注释。这里分享一个实践无论是 MySQL 还是 Oracle建表语句里就把注释写好养成这个习惯后面写文档时能省一大半时间。5.4 查不到默认值或默认值不对有时候information_schema.COLUMNS里的COLUMN_DEFAULT显示为 NULL不是真的没默认值而是某些数据库版本对默认值的存储做了优化要查另外的系统表。PostgreSQL 就得查pg_attrdef这在前面已经提过。SQL Server 则要注意默认值可能是绑定了DF_开头的约束不一定直接在列上显示。5.5 快速排查的万能三步法如果你发现上面某个库的查询结果不对先别慌按这个顺序查先跑一条最简单的全表字段查询不带 WHERE确认当前库/账号能拿到元数据再核对库名、模式名、表名的大小写和拼写尤其注意 Oracle 和 PostgreSQL最后打印完整 SQL 和参数逐项检查是否用了错误的过滤条件这套方法救过我很多次每次以为是数据库版本差异的问题最后九十都是连接串配错了库。写在最后的实践感悟我在实际项目里折腾这些查询已经快十年最大的体会是查字段信息这事情本身不难难的是你能不能在自己的工作流里形成一套方法论。比如我现在的习惯是接一个新项目先写一个字典导出脚本把核心表的结构一次性拉到本地开发过程中遇到接口报错第一反应不是看代码而是先确认表字段和接口字段对不对得上提交文档前再用脚本比对一遍线上表和设计文档的差异。这套流程看起来朴素但每次都能帮我省下大量排查时间。最后再分享一个小技巧不管用什么数据库都建议把常用的字段查询 SQL 保存成代码片段绑定快捷键。DataGrip 里我绑定的是scshow columns敲两下就出来一整套带注释的字段清单比任何可视化操作都快。你可能觉得这些细节不值一提但在赶工到半夜的时候少敲几行代码、少点几次鼠标真的能让人心情好不少。希望这篇手册能帮你在查字段信息这件事上少走弯路把时间花在更重要的事情上。

数据库表字段信息查询全攻略：主流数据库通用手册

相关推荐

2026年AI开发技能生态与云原生实践

Arm-2D源码深度评测：Cortex-M图形加速的选型与落地实践

Jenkins CICD服务器搭建与实战指南

更多资讯

darwin-vm：用QEMU仿真Apple Silicon，零成本调试XNU内核

ESP32-S3 实时音频链路设计：从麦克风到AI陪伴的端侧闭环

一条Pod启动流程，彻底讲清K8s容器编排的核心原理

德承工控机DX-1300的Ubuntu NPU驱动安装教程与避坑指南

论文降AI率实用指南：5个免费技巧彻底改写AI腔

如何判断 kitty 打开大量窗口后内存占用高是否为内存泄漏（valgrind massif）

今日更新

Linux 内核 ARM 虚拟内存布局全解析：从 4GB 地址空间划分到源码级验证

AIGC降重工具测评与教育应用指南

数据容灾核心指标与实战方案解析

本周精选

超人会飞不算本事：系统稳定依赖清晰规则与边界设计

超人VS蜘蛛侠：拆解超级IP的影响力与传播方法论

基于CNN的调制信号识别：MATLAB实现时频图分类实战

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？