怎么在导出时保留字段注释和表说明_完整数据字典生成-phpMyAdmin-PHP中文网

MySQL导出SQL时COMMENT不生效，因5.7+默认不包含注释，需显式启用或改用information_schema查询；Navicat等工具需手动勾选导出注释选项；直接查information_schema最可控，注意NULL与空字符串处理差异。

导出 SQL 时 `COMMENT` 不生效？检查 MySQL 版本和导出命令参数

mysql 5.7+ 默认导出（如 mysqldump）不会包含字段注释（comment）和表说明（table comment），除非显式启用。5.6 及更早版本甚至不支持表级 comment 持久化到 dump 中。

实操建议：

用 mysqldump --comments --complete-insert --no-create-info 仍不够，关键要加 --skip-triggers --skip-routines --skip-events 避免干扰，但真正起作用的是 --no-create-info 关闭建表语句后，再手动补上带 COMMENT 的 CREATE TABLE —— 更稳妥的做法是不用 mysqldump 直接导结构，改用查询 information_schema
确认你的 MySQL 实例开启 show_compatibility_56=OFF（默认），否则 information_schema.COLUMNS.COLUMN_COMMENT 可能为空
如果用 Navicat / DBeaver 导出，务必勾选「导出注释」或「Include comments」类选项，不同客户端开关位置差异大，常被忽略

用 `SELECT` 从 `information_schema` 拼数据字典最可控

依赖 GUI 工具或 mysqldump 往往漏字段注释、空表说明、字符集/排序规则细节。直接查 information_schema 虽要写 SQL，但字段全、逻辑透明、可复用。

实操建议：

字段级注释取自 information_schema.COLUMNS.COLUMN_COMMENT，不是 EXTRA 或 PRIVILEGES
表说明来自 information_schema.TABLES.TABLE_COMMENT，注意该字段最大长度为 60 字符，超长会被截断
别忘了关联 information_schema.STATISTICS 补主键/索引信息，否则字典里没有「是否主键」「是否唯一」等关键标记

示例片段：

SELECT 
  t.TABLE_NAME,
  t.TABLE_COMMENT,
  c.COLUMN_NAME,
  c.COLUMN_TYPE,
  c.IS_NULLABLE,
  c.COLUMN_DEFAULT,
  c.COLUMN_COMMENT
FROM information_schema.TABLES t
JOIN information_schema.COLUMNS c ON t.TABLE_SCHEMA = c.TABLE_SCHEMA AND t.TABLE_NAME = c.TABLE_NAME
WHERE t.TABLE_SCHEMA = 'your_db_name'
ORDER BY t.TABLE_NAME, c.ORDINAL_POSITION;

生成 Markdown 或 Excel 时，NULL 注释和空字符串处理不一致

COLUMN_COMMENT 为 NULL 和空字符串 '' 在导出后显示效果一样（都成空白），但含义不同：前者是未设注释，后者是刻意留空。下游工具（如 Pandas 读 CSV、Typora 渲染 Markdown）对二者处理方式可能不同，导致字典可信度下降。

实操建议：

SQL 查询中统一用 COALESCE(c.COLUMN_COMMENT, '(无)') 替换 NULL，避免歧义；空字符串可保留原样或统一转为 '(空)'
导出为 CSV 时，用 SELECT ... INTO OUTFILE 要指定 FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'，否则含换行的注释会破坏行列结构
若转 Excel，Python 用 pandas.DataFrame.to_excel() 时设 na_rep='(无)'，比事后在 Excel 里查找替换更可靠

PostgreSQL / SQL Server 用户别套用 MySQL 方案

各数据库存储注释的位置和查询方式完全不同：PostgreSQL 存在 pg_description 系统表，SQL Server 用 sys.extended_properties，字段名、关联条件、甚至注释是否支持多语言都不同。硬搬 MySQL 的 information_schema 查询会返回空结果。

实操建议：

PostgreSQL 查字段注释：

SELECT 
  c.relname AS table_name,
  a.attname AS column_name,
  d.description AS column_comment
FROM pg_class c
JOIN pg_attribute a ON a.attrelid = c.oid
JOIN pg_description d ON d.objoid = c.oid AND d.objsubid = a.attnum
WHERE c.relkind = 'r' AND a.attnum > 0;

SQL Server 查表说明：SELECT obj.name, ep.value FROM sys.objects obj JOIN sys.extended_properties ep ON obj.object_id = ep.major_id WHERE ep.name = 'MS_Description' AND ep.class = 1
不要试图用同一套脚本兼容多库——注释字段本身就不标准，强行抽象只会增加维护成本

字段注释和表说明不是“导出就自带”的元数据，而是需要主动提取、显式拼接、谨慎处理空值的离散信息。最容易被忽略的是：不同环境（开发/测试/生产）的 MySQL 配置可能不一致，导致同一份 dump 在 A 环境有注释、B 环境没有，排查时容易误判为工具问题。