DESC 命令仅显示字段基本属性（如类型、是否为空、键类型、默认值、额外属性），不展示 CHECK、外键、生成列、注释等约束信息；完整元数据应使用 SHOW CREATE TABLE 或查询 INFORMATION_SCHEMA.COLUMNS。
DESC 命令查不到字段的约束信息
MySQL 的 DESC（或 DESCRIBE）只是 SHOW COLUMNS FROM 的快捷写法，它只显示字段名、类型、是否为空、键类型（如 PRI）、默认值和额外属性（如 auto_increment），但**不展示 CHECK、FOREIGN KEY、生成列表达式、列注释等约束细节**。
常见错误现象：你执行了 DESC users;，发现 email 字段标着 UNI，但不知道它是唯一索引还是 UNIQUE 约束；或者根本看不到 CHECK (age >= 0) 这类定义。
- 真正要查完整约束，得用
SHOW CREATE TABLE users;—— 它返回建表语句，所有约束一目了然 - 如果只想看外键，用
SELECT * FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'users'; -
DESC对视图也有效，但对视图它只显示列名和类型，其他全是NULL，别指望它反映底层逻辑
用 SHOW COLUMNS 和 SHOW FULL COLUMNS 区分“是否显示注释”
SHOW COLUMNS FROM users; 和 DESC users; 输出完全一致；而 SHOW FULL COLUMNS FROM users; 多出两列：Collation 和 Comment —— 后者就是你加在字段上的注释（比如建表时写的 name VARCHAR(50) COMMENT '用户真实姓名'）。
使用场景：团队协作中靠注释说明字段用途，光看字段名不够时，必须用 FULL 版本。
-
SHOW COLUMNS不显示注释，SHOW FULL COLUMNS显示（前提是建表时写了COMMENT） -
SHOW FULL COLUMNS的Type列会包含长度、是否无符号、是否 ZEROFILL 等细节，比DESC更精确 - 注意：如果字段用了生成列（
GENERATED ALWAYS AS），SHOW FULL COLUMNS的Extra列会显示STORED GENERATED或VIRTUAL GENERATED，这是DESC完全不体现的
information_schema.tables 和 columns 表查字段类型更可靠
当需要程序化读取字段类型（比如写一个自动文档生成脚本），别依赖 DESC 的文本输出格式——它可能随 MySQL 版本微调，且字段顺序不固定。直接查 INFORMATION_SCHEMA.COLUMNS 表最稳妥。
示例：查 users 表所有字段名、类型、是否为空、默认值、注释：
SELECT COLUMN_NAME, DATA_TYPE, IS_NULLABLE, COLUMN_DEFAULT, COLUMN_COMMENT FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'your_db_name' AND TABLE_NAME = 'users' ORDER BY ORDINAL_POSITION;
性能与兼容性影响：该查询走系统表，极快；但要注意 TABLE_SCHEMA 必须显式指定，因为 INFORMATION_SCHEMA 是全局的，不设条件会扫所有库。
-
DATA_TYPE是标准类型名（如varchar、int），不带括号长度；想拿完整类型字符串，看COLUMN_TYPE字段（如varchar(255)） -
CHARACTER_MAXIMUM_LENGTH对字符类型才有意义，数值类型是NULL - MySQL 8.0+ 中，
GENERATION_EXPRESSION字段可查生成列的表达式，DESC完全不提供这个
DESC 在不同 MySQL 版本里行为一致，但别把它当元数据权威来源
DESC 从 5.6 到 8.0 行为基本没变，这点很省心。但它本质是语法糖，不是元数据接口，所以永远不要用它判断“某个约束是否存在”。比如你想确认某字段有没有 NOT NULL，看 DESC 的 Null 列（YES/NO）可以；但想确认有没有 CHECK，它就彻底失能。
容易踩的坑：有人把 DESC 当成“结构快照”，导出后直接用于重建表——结果丢失所有约束、索引、分区定义，甚至默认字符集。
- 备份/迁移场景下，唯一可信的是
SHOW CREATE TABLE输出 - ORM 框架（如 Django、Laravel）读取结构时，底层几乎都走
INFORMATION_SCHEMA，而非DESC - 如果你在写自动化 SQL 工具，对字段类型的判断逻辑，应优先基于
DATA_TYPE+NUMERIC_PRECISION+DATETIME_PRECISION组合，而不是解析DESC的Type字符串
复杂点在于：字段类型在 MySQL 里其实有三层抽象——用户写的建表语句、服务器内部存储的类型标识、以及客户端看到的显示字符串。DESC 只暴露最表层，而真正做类型推断或兼容性检查时，得往下挖两层。
