导出MySQL/PostgreSQL数据字典需绕开information_schema/pg_dump缺陷：MySQL用mysqldump --no-data --skip-triggers --skip-routines+解析，PostgreSQL需联合pg_description等系统表查询；字典必须与DDL迁移脚本版本绑定，禁用GUI导出和自动ER图同步。
导出 MySQL 数据库完整数据字典要绕开 information_schema 的坑
直接查 information_schema.columns 会漏掉注释、默认值表达式、生成列定义，而且不同 mysql 版本对 column_comment 和 extra 字段的填充逻辑不一致。真正能覆盖全量元信息的是用 show create table 配合解析，但手动做太重——推荐用 mysqldump --no-data --skip-triggers --skip-routines 先拿到建表语句，再用脚本提取字段级描述。
-
mysqldump --no-data不导出数据，但保留COMMENT、DEFAULT、GENERATED ALWAYS AS等关键定义 - 必须加
--skip-triggers和--skip-routines，否则输出里混入存储过程和触发器，干扰字段结构识别 - 如果库中有
JSON类型字段或 8.0+ 的隐藏列（INVISIBLE），需额外检查SHOW COLUMNS FROM tbl输出中的Extra列是否含STORED GENERATED或INVISIBLE
PostgreSQL 用 pg_dump --schema-only 不够，得补 pg_description
pg_dump --schema-only 能导出表结构和约束，但字段注释、表注释、列排序顺序、COLLATION 设置全丢了。这些信息存在系统表 pg_description 和 pg_attribute 里，必须联合查询。
- 字段注释查法：
SELECT obj_description(c.oid) AS table_comment, col_description(c.oid, a.attnum) AS column_comment FROM pg_class c JOIN pg_attribute a ON a.attrelid = c.oid WHERE c.relname = 'your_table' AND a.attnum > 0 - 注意
pg_description只存显式加过COMMENT ON COLUMN的内容，没加过的返回空，别误以为字段没注释 - 如果用了
ENUM或DOMAIN类型，pg_dump --schema-only不会展开类型定义，得单独导出pg_type相关部分
团队协作时数据字典版本必须和数据库迁移脚本绑定
只导出某次快照的字典没意义。字典不是静态文档，它必须和 ALTER TABLE 脚本、Flyway/Liquibase 的 V1__init.sql、V2__add_user_status.sql 对齐。否则开发改了字段但没更新字典，下游就按旧结构写代码。
- 每次提交 DDL 变更时，同步跑一次字典生成命令，把输出文件（如
schema_v2.3.json）和迁移脚本一起提交到 Git - 禁止用 GUI 工具点出来的“导出字典”功能——那些工具不记录操作时间戳，也不带版本号，合并冲突时根本分不清谁新谁旧
- 如果用 DBT 或 DataLens 做数据建模，字典应从
sources.yml或models/下的 SQL 文件反向生成，而不是从生产库直抽
对接图纸（如 ER 图）时别信自动生成工具的“一键同步”
像 MySQL Workbench 或 DBeaver 的反向工程能画出表关系，但外键名、索引命名规则、逻辑删除标记字段（如 is_deleted）这类业务语义，工具压根不会标出来。图纸上缺这些，开发联调时就会反复问“这个字段到底是不是软删？”
- ER 图里的每个实体框旁，手写标注字段是否参与业务主键、是否为审计字段（
created_at/updated_by）、是否被下游系统强依赖 - 外键连线旁注明是“级联删除”还是“置空”，别只写
FK_user_id - 如果用了分库分表中间件（如
ShardingSphere），图纸必须标出分片键和广播表，否则字典里字段再全也没法还原路由逻辑
字典和图纸最常断连的地方，是字段生命周期管理——比如一个 temp_flag 字段上线时说“临时用三个月”，结果半年后还在，但字典没标记已过期，图纸也没灰掉它。这种状态没人维护，就只能靠每次 CR 时人工对一遍 git blame 和 SHOW CREATE TABLE 输出。
