DESCRIBE最快但不跨库通用；查字段注释、约束等须用系统元数据表：MySQL查INFORMATION_SCHEMA.COLUMNS，PostgreSQL用information_schema.columns或pg_columns，SQL Server需联查sys.columns、sys.types和sys.extended_properties。
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需要 JOINsys.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 走到底。
