SQL如何查询表的结构信息？DESCRIBE与元数据查询
在数据库开发和维护中，查看表结构是再常见不过的操作。但这里有个关键分野：用DESCRIBE最快，但它不跨库通用；想查字段注释、约束，或者需要兼容PostgreSQL、SQL Server，就必须转向系统元数据表。 这不仅仅是语法差异，更关乎代码的可移植性和信息的完整性。
MySQL 中 DESCRIBE 和 SHOW COLUMNS 的实际区别
先说个冷知识：DESCRIBE table_name 其实是 SHOW COLUMNS FROM table_name 的一个快捷别名，两者输出的内容完全一致。它们能快速告诉你字段名、类型、是否允许NULL、键信息、默认值和额外属性。
但是，这就够了吗？远远不够。这些命令不包含字段注释、外键定义、索引详情或约束条件。很多开发者第一次踩坑，就是在这里。
举个例子，你看到DESCRIBE输出里有个NULL列，显示“YES”或“NO”——这可不是SQL里的NULL字面量，它仅仅表示该字段是否允许为空而已。这种细节上的误判，在复杂排查中很要命。
- 想快速扫一眼字段类型和主键？用
DESCRIBE users没问题，够快。 - 需要知道
created_at字段的 COMMENT 是“用户注册时间”？抱歉，DESCRIBE完全不返回这一列。 - 表里用
TINYINT(1)来存储布尔值？DESCRIBE只会老实显示原始类型，不会提示你“这其实是个逻辑布尔型”。
查字段注释必须用 INFORMATION_SCHEMA.COLUMNS
那么，完整信息藏在哪里？答案是系统库。MySQL把表的完整结构信息都放在了 INFORMATION_SCHEMA 这个虚拟库里，其中 COLUMNS 表就包含了 COLUMN_COMMENT 字段，这才是获取注释的唯一可靠来源。
SELECT COLUMN_NAME, DATA_TYPE, IS_NULLABLE, COLUMN_DEFAULT, COLUMN_COMMENT FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'mydb' AND TABLE_NAME = 'users' ORDER BY ORDINAL_POSITION;
执行这类查询时，有几个细节必须留意：
TABLE_SCHEMA（数据库名）必须显式指定。别依赖当前USE的库，否则跨库查询很容易漏掉结果。- 排序时用
ORDINAL_POSITION而不是COLUMN_NAME。前者代表字段定义的物理顺序，这样才能还原建表时的真实结构。 DATA_TYPE返回的是基础类型（比如varchar），不包含长度。想看到完整的varchar(255)，得额外拼接CHARACTER_MAXIMUM_LENGTH字段。
PostgreSQL 和 SQL Server 怎么查结构？语法差异很关键
一旦跳出MySQL的舒适区，事情就变得有趣了。PostgreSQL 压根没有 DESCRIBE 这个命令。在psql命令行里，你可以用 \d table_name 作为等价操作，但这属于客户端指令，没法直接写在应用代码里。
在程序内部，标准做法是查询系统表。可以用information_schema.columns（兼容性更好），或者PostgreSQL特有的pg_catalog.pg_columns。
-- PostgreSQL 标准写法（兼容性更好）
SELECT column_name, data_type, is_nullable, column_default,
col_description(
(SELECT oid FROM pg_class WHERE relname = 'users'),
ordinal_position
) AS comment
FROM information_schema.columns
WHERE table_name = 'users' AND table_schema = 'public';
至于SQL Server，它的系统视图又是另一套体系。查结构需要关联 sys.columns 和 sys.types，查注释则要去找 sys.extended_properties。
- 别直接SELECT
sys.columns就完事——里面的user_type_id是个数字，必须JOINsys.types表才能转成varchar这类可读的类型名。 - 字段注释存在
sys.extended_properties里，筛选时要注意：class=1且class_desc='OBJECT_OR_COLUMN'，同时minor_id > 0的记录才代表字段级的注释。 - SQL Server也有
INFORMATION_SCHEMA视图，但字段信息不全，比如不暴露is_identity这种属性。真要获取完整信息，还是得查系统视图。
为什么生产环境建议统一走元数据查询，而不是依赖 DESCRIBE
看到这里，你可能会想：DESCRIBE用着挺顺手，为什么非要换？原因主要有两个：可移植性和信息完整性。
DESCRIBE 是MySQL特有的语法。一旦把它写死在ORM或数据迁移工具里，就意味着你的代码和MySQL绑定了，失去了跨数据库的灵活性。未来如果想迁移到PostgreSQL，这就是个技术债。
更隐蔽的问题是权限。一个普通数据库用户，可能拥有对某张表的SELECT权限，但没有访问 INFORMATION_SCHEMA 的权限。这时，他执行 DESCRIBE 能成功，却查不到注释。在线上紧急排查问题时，这种“结构可见但关键注释丢失”的情况，很容易导致误判。
真正的复杂性在于，不同数据库对“相同概念”的元数据，存放位置天差地别。就拿外键约束来说：MySQL放在 INFORMATION_SCHEMA.KEY_COLUMN_USAGE，PostgreSQL放在 pg_constraint，SQL Server则放在 sys.foreign_keys。如果你的业务需要自动生成数据库文档，或者校验不同环境间的schema一致性，就必须为每个数据库写一套查询逻辑，没有一招通吃的办法。
所以说，从DESCRIBE切换到系统元数据查询，看似是多写了几行代码，实则是为了代码的健壮性和未来的可维护性铺路。 尤其是在微服务和多数据库技术栈并存的今天，这份前期投入非常值得。
