MySQL的information_schema不包含视图、函数等定义，需用SHOW CREATE或查询mysql系统库补全；PG需组合查询系统目录表导出完整字典；SQL Server中is_nullable不能反映隐式非空约束，须关联约束表校验；环境字典需带哈希指纹实现精准比对。
导出数据字典时 information_schema 查不到视图或函数定义？
mysql 默认的 information_schema 只暴露元数据结构（如表名、字段类型），不包含视图 sql、存储过程逻辑、函数体等。想导出完整字典，必须主动查 mysql 系统库或用 show create 类命令补全。
- 对视图：用
SHOW CREATE VIEW `view_name`获取定义，不能只依赖COLUMNS表 - 对存储过程/函数：查
mysql.proc（5.7）或mysql.routines（8.0+），但要注意definer字段可能含敏感账号，导出前需脱敏 - 触发器同理：
SHOW CREATE TRIGGER比TRIGGERS表更可靠，后者不返回触发逻辑正文
PostgreSQL 怎么一次性导出含注释、约束、索引的字典？
PG 的 pg_dump --schema-only 会输出 DDL，但不含列注释（COMMENT ON COLUMN）和部分约束细节（如 CHECK 表达式原始写法）。得组合查询系统目录表手动拼装。
- 核心表是
pg_class（表/索引）、pg_attribute（字段）、pg_description（注释）、pg_constraint（约束） - 别直接用
\d+命令结果——它格式不规整，难解析；应写 SQL 查询并用psql -t -c "..." > dict.sql导出纯文本 - 注意
pg_attribute.attisdropped = true的字段要过滤掉，否则导出会混入已删除字段的残留信息
SQL Server 导出字典后发现 sys.columns 的 is_nullable 和实际不一致？
这是常见误判点：sys.columns.is_nullable 只反映字段定义时是否允许 NULL，但不体现默认约束（如 DEFAULT GETDATE()）或触发器逻辑带来的隐式非空行为。导出字典若只依赖该字段，会漏掉业务层强约束。
- 必须连查
sys.default_constraints和sys.check_constraints，看是否有NOT NULL类 CHECK 或 DEFAULT + NOT FOR REPLICATION 组合 -
sys.extended_properties存列级注释，但只在显式执行sp_addextendedproperty后才有，很多老库为空——别默认假设它存在 - 导出脚本里加个校验步骤：对每个字段跑
SELECT COUNT(*) FROM table WHERE column IS NULL（采样 1w 行），比元数据更真实
模块化管理时，不同环境（dev/staging/prod）字典版本怎么对齐？
靠人肉比对 SQL 文件或截图根本不可行。关键不是“存哪里”，而是“怎么标记变更”。每次导出必须附带环境指纹和结构哈希值。
- 导出文件名强制含三要素：
dict_${DB_NAME}_${ENV}_${TIMESTAMP}_${SHA256_HASH}.sql，哈希基于排序后的 DDL 文本生成 - 用
git diff对比两个哈希文件，能立刻定位新增表、字段类型变更、约束删减——别用文本 diff 工具直接比原始导出，顺序不固定会误报 - 禁止把字典当配置文件提交到主分支；建单独
data-dict仓库，用 GitHub Actions 自动触发导出（每天凌晨连 prod 只读账号拉一次），避免人为漏更
真正麻烦的从来不是导出动作本身，而是字段语义漂移：同一个 status 字段，在订单表里是枚举值，在日志表里却是 JSON 字符串。字典文档再全，也救不了没同步更新的业务代码注释。
