DESCRIBE 不显示字段注释，因其仅返回字段名、类型、是否为空等基础信息，不包含 COMMENT、字符集、排序规则及生成列表达式；SHOW CREATE TABLE 虽权威但易漏看 ENGINE、CHARSET、COLLATE 及末尾的生成列定义；information_schema.COLUMNS 是唯一程序化获取完整元数据的方式，需严格限定库表名并关注 COLUMN_COMMENT 和 ORDINAL_POSITION；mysqldump -d 并非更可靠，受连接参数和条件注释影响，可能隐藏外键或导致语法错误。
DESCRIBE 表名为什么有时看不到完整字段注释？
因为 DESCRIBE（或简写 DESC）只返回基础列信息：字段名、类型、是否为空、键类型、默认值、额外属性。它**不显示 COMMENT 注释**，也不展示字符集、排序规则、生成列表达式等细节。
- 适合快速查看字段是否存在、类型是否匹配、主键/自增是否设置正确
- 在 MySQL 8.0+ 中，
DESCRIBE对 JSON 类型字段会显示为json，但不会体现约束或存储格式差异 - 如果表用的是
utf8mb4_0900_as_cs这类新排序规则，DESCRIBE输出里完全不体现，容易误判大小写敏感行为
SHOW CREATE TABLE 能看到什么，又容易漏看哪几行？
SHOW CREATE TABLE 返回建表语句本身，是还原表结构最权威的来源，但输出是单行字符串（MySQL CLI 默认折行显示），关键信息容易被忽略。
- 必须检查
ENGINE=后面的引擎类型（比如InnoDBvsMyISAM），不同引擎对事务、锁、全文索引支持完全不同 - 留意
DEFAULT CHARSET=和COLLATE=所在行——同一张表不同列可能显式指定了不同 collation，而这里只显示表级默认值 - 生成列（GENERATED COLUMN）、虚拟列、全文索引定义都在建表语句末尾，如果输出被截断（如客户端设置
max_allowed_packet过小），这部分直接丢失
information_schema.COLUMNS 表怎么查才不踩坑？
这是唯一能程序化获取完整元数据的方式，但字段多、逻辑绕，新手常查错表或漏条件。
- 必须加
WHERE table_schema = 'your_db' AND table_name = 'your_table'，否则默认查所有库，结果量大且权限不足时会报错 -
COLUMN_COMMENT字段才是真正的注释内容，别和EXTRA（比如auto_increment）或PRIVILEGES混淆 -
ORDINAL_POSITION是列顺序依据，不是COLUMN_NAME字典序；想导出建表语句片段时，务必按这个排序，否则字段顺序错乱 - MySQL 8.0+ 中，
GENERATION_EXPRESSION字段存的是生成列公式，但内容是转义后的字符串，直接拼 SQL 会出错
用 mysqldump -d 看结构，比 SHOW CREATE TABLE 更可靠吗？
不一定。虽然 mysqldump -d（即 --no-data）输出也是建表语句，但它受客户端连接参数和服务器配置影响更大。
- 如果连接时没加
--skip-extended-insert，建表语句可能被包进一个带注释的长 INSERT 模板里，反而更难读 -
mysqldump默认会加上/*!40101 SET ... */这类条件注释，用于兼容老版本，但如果你复制出来直接执行，可能因版本不匹配导致语法错误 - 当表有外键且引用了其他库的表时，
mysqldump -d可能省略FOREIGN KEY定义（取决于--skip-foreign-key-checks和权限），而SHOW CREATE TABLE不会
DESCRIBE 快速过一遍字段骨架；确认需要注释、字符集、约束细节时，立刻切到 SHOW CREATE TABLE 并逐行盯紧 ENGINE、CHARSET、COLLATE、COMMENT 出现的位置；真要写脚本批量处理，就老老实实查 information_schema.COLUMNS，别信任何“自动格式化”工具对列顺序或表达式的猜测。 
