SHOW CREATE TABLE 更可靠，因其输出可执行建表语句，包含注释、默认值、自增、字符集等全部元数据；DESCRIBE 仅返回基础字段信息，缺失关键字典内容。
导出表结构时为什么 SHOW CREATE TABLE 比 DESCRIBE 更可靠
因为 describe 只返回字段名、类型、是否为空等基础信息，缺失注释、默认值表达式、自增属性、字符集、排序规则等关键字典字段；而 show create table 输出的是可执行的建表语句，包含全部元数据，是生成规范字典的源头。
实操建议：
- 在 Navicat 查询窗口中直接运行
SHOW CREATE TABLE `user`;，复制结果后用正则提取COMMENT、DEFAULT、AUTO_INCREMENT等字段 - 避免依赖 Navicat「对象信息」面板里的「备注」栏——它只显示表级注释，不展示列级
COMMENT - MySQL 8.0+ 中，
information_schema.COLUMNS的COLUMN_COMMENT字段才真正同步了列注释，但 Navicat 导出「表数据」功能默认不包含该视图字段
用 Navicat 批量导出所有表结构的两个可行路径
Navicat 本身没有「一键导出全库字典」按钮，但可通过组合操作逼近目标：要么导出 SQL（含 DDL），要么导出查询结果为 Excel。前者保真度高，后者易读但需补全信息。
实操建议：
- 右键数据库 →「转储 SQL 文件」→ 勾选「仅结构」→ 在高级选项里务必打开「添加 DROP TABLE 语句」和「添加注释」，否则导出的 SQL 会丢失
COMMENT - 新建查询，执行：
SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE, IS_NULLABLE, COLUMN_DEFAULT, COLUMN_COMMENT, ORDINAL_POSITION FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'your_db_name' ORDER BY TABLE_NAME, ORDINAL_POSITION;
→ 右键结果集 →「导出向导」→ 选 Excel，注意勾选「导出列标题」 - 别用「数据库快照」功能——它生成的是 HTML 报告，字段对齐混乱，且无法导出
COLUMN_COMMENT内容
导出的 Excel 字典里中文注释乱码？重点查这三个地方
不是 Navicat 编码设置问题，而是导出链路中某环默认用了系统 locale 编码（如 Windows-1252），导致 UTF-8 存储的 COLUMN_COMMENT 被错误解码。
实操建议：
- 导出前，在 Navicat「工具」→「选项」→「连接」→「MySQL」里把「字符集」设为
utf8mb4（不是utf8） - 导出 Excel 时，「导出向导」第 3 步「编码」下拉菜单必须手动选
UTF-8，不能留空或选「系统默认」 - 如果已导出乱码 Excel，不要双击打开——用 Excel「数据」→「从文本/CSV」导入，编码选
UTF-8，否则 Excel 会自动按 ANSI 解析
想自动补全「字段用途」「业务规则」这类非数据库原生字段？别硬改导出逻辑
Navicat 导不出你脑补的业务含义，强行在 SQL 或 Excel 里手填，下次结构变更就全失效。真正可持续的做法是把字典维护动作前置到开发流程里。
实操建议：
- 在建表语句的
COLUMN_COMMENT里写真实业务描述，例如：user_status TINYINT COMMENT '0-未激活 1-正常 9-注销'，这样导出即用 - 用
mysqldump --no-data --skip-triggers --compact your_db替代 Navicat 导出，再用 Python 脚本解析 SQL 提取注释——比改 Navicat 设置更可控 - 如果团队用 Git 管理建表 SQL，字典就天然存在，Navicat 导出只是临时验证手段，不必追求“全自动”
字典不是越全越好，而是越准越省事。字段注释写在哪、谁来维护、怎么同步，这些比导出按钮点几次重要得多。
