SQL如何查询表的结构信息？DESCRIBE与元数据查询-SQL-PHP中文网

describe最快但不跨库通用；查字段注释、约束等须用系统元数据表：mysql查information_schema.columns，postgresql用information_schema.columns或pg_columns，sql server需联查sys.columns、sys.types和sys.extended_properties。

sql如何查询表的结构信息？describe与元数据查询

MySQL 用 DESCRIBE 最快，但跨数据库不通用；想查字段注释、约束或兼容 PostgreSQL/SQL Server，必须查系统元数据表。

MySQL 中 `DESCRIBE` 和 `SHOW COLUMNS` 的实际区别

DESCRIBE table_name 是 SHOW COLUMNS FROM table_name 的别名，两者输出完全一致，都只返回基础字段信息（字段名、类型、是否为空、键、默认值、额外属性），但不包含字段注释、外键定义、索引详情或约束条件。

常见误判：看到 DESCRIBE 输出里有 NULL 列，就以为能判断是否允许 NULL —— 实际上它显示的是 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 怎么查结构？语法差异很关键

PostgreSQL 没有 DESCRIBE，等价命令是 \d table_name（psql 命令行），但这是客户端指令，不能在应用代码里执行。程序内必须用标准 SQL 查询 pg_columns 或 information_schema.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 需要 JOIN sys.types 才能转成 varchar 这类可读名
字段注释存在 sys.extended_properties 里，class=1 and class_desc='OBJECT_OR_COLUMN'，且 minor_id > 0 才是字段级注释
INFORMATION_SCHEMA 在 SQL Server 中字段有限，比如不暴露 is_identity，必须查系统视图

为什么生产环境建议统一走元数据查询，而不是依赖 `DESCRIBE`

DESCRIBE 是 MySQL 特有语法，写死在代码里会让 ORM 或迁移工具失去数据库可移植性。更隐蔽的问题是权限：普通用户可能有表 SELECT 权限，但没权限访问 INFORMATION_SCHEMA —— 这时 DESCRIBE 仍能执行，导致“结构可见但注释丢失”，线上排查时容易误判。

真正复杂的点在于：不同数据库对“相同概念”的元数据存放位置不一致。比如外键约束，MySQL 在 INFORMATION_SCHEMA.KEY_COLUMN_USAGE，PostgreSQL 在 pg_constraint，SQL Server 在 sys.foreign_keys。如果业务需要自动生成文档或校验 schema 一致性，必须按目标数据库分路径处理，没法一套 SQL 走到底。