导出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类型字段，或者使用了MySQL 8.0+的隐藏列（INVISIBLE），建议额外检查SHOW COLUMNS FROM tbl命令输出中的Extra列，确认其中是否包含STORED GENERATED或INVISIBLE等标记。
PostgreSQL 用 pg_dump --schema-only 不够，得补 pg_description
转到PostgreSQL，很多人会习惯性使用 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或DBea ver这类工具的反向工程功能，确实能根据数据库结构自动绘制出表关系图。但是，外键约束的名称、索引的命名规则、以及像逻辑删除标记字段（例如 is_deleted）这类承载业务语义的信息，工具通常无法自动识别并标注。图纸上缺少这些关键说明，开发联调时就免不了反复确认：“这个字段到底是不是用来软删除的？”
- 手动补充业务语义：在ER图的每个实体框旁边，需要手动标注关键信息，例如：字段是否参与业务主键、是否为审计字段（如
created_at/updated_by）、是否被下游系统强依赖。 - 明确关系细节：在外键关系连线旁，应注明是“ON DELETE CASCADE”（级联删除）还是“SET NULL”（置空），不能只写一个
FK_user_id了事。 - 考虑分片场景：如果使用了ShardingSphere等分库分表中间件，必须在图纸上明确标出分片键和广播表，否则数据字典字段再全，也无法还原实际的数据库路由逻辑。
数据字典与ER图最容易脱节的地方，往往在于字段的生命周期管理。举个例子，一个名为 temp_flag 的字段上线时约定“临时使用三个月”，但半年后它依然存在于表中。如果数据字典没有标记其已过期，ER图也没有将其灰显或备注，这种状态就无人维护。最终，每次代码评审时，都只能依靠人工反复核对 git blame 历史记录和 SHOW CREATE TABLE 的当前输出来进行判断，效率低下且容易出错。
