简介致远OA V8.1 数据字典以PDF格式完整呈现OA系统核心数据库表结构适合企业OA运维人员、二次开发工程师及数据库管理人员查阅。资源共1个PDF文件压缩包约2.2MB内容便于随身查看与检索。目前已有2600余人学习使用。该数据字典重点收录通讯录ADDRESSBOOK表等核心表的字段定义逐一说明字段名称、数据类型、是否必填及用途涵盖ID、成员ID、创建与修改日期以及EXT_ATTR_1至EXT_ATTR_70等多达70个扩展字段明确区分文本、数字、日期、枚举、选人、选部门、选岗位等不同类型可帮助开发者快速理解表设计意图减少逆向分析成本为系统维护、数据迁移、功能扩展和自定义业务字段开发提供可靠参考。1. 致远OA V8.1 数据字典先对库再动手少走一周弯路我第一次拿到致远OA V8.1 数据字典是在做人员组织同步的时候。界面上填得好好的扩展字段直接查 ADDRESSBOOK 表却是空的翻了一天代码才发现字段落到了另一张表里。这本字典解决的就是这类问题它把 V8.1 核心模块的表名、字段名、数据类型、是否必填、字段注释一次性列清楚覆盖通讯录、考勤、代理设置、AI 自动处理、讨论版块等模块开发前拿它和线上库对一遍多数坑能提前绕开。适合做集成、报表、二次开发的一线工程师如果你是纯 OA 使用方这本文档帮不上什么忙。另外提醒一句字典开头标着 V5 字样说明大量表结构是从 V5 时代沿用过来的V8.1 并没有重新设计理解这一点能省掉很多无谓的猜测。2. 通讯录模块ADDRESSBOOK 主表与 70 个扩展字段的语义分组2.1 五张表的分工主表、成员、设置、范围、分组致远 V8.1 的通讯录不是一张表而是五张表协作。ADDRESSBOOK 存内部人员的通讯录主数据ADDRESSBOOK_MEMBER 存外部联系人ADDRESSBOOK_SET 存查看、导出、显示配置ADDRESSBOOK_SET_SCOPE 存这些配置作用于哪些组织范围ADDRESSBOOK_TEAM 与 ADDRESSBOOK_TEAM_MEMBERS 存个人组/系统组及组成员关系。做内部人员查询、外部联系人导入、通讯录权限控制时分别命中不同表混在一起查必然出问题。表名职责关键字段ADDRESSBOOK内部人员通讯录主表ID、MEMBER_ID、CREATE_DATE、UPDATE_DATE、EXT_ATTR_1~70ADDRESSBOOK_MEMBER通讯录外部联系人ID、NAME、COMPANY_NAME、MOBILEPHONE、EMAIL、CATEGORY_IDADDRESSBOOK_SET通讯录设置VIEW_SCOPE、KEY_INFO、EXPORT_PRINT、DISPLAY_COLUMN、M3_SET、ZX_SETADDRESSBOOK_SET_SCOPE设置生效范围ADDRESSBOOK_SET_ID、USER_ID、USER_TYPEADDRESSBOOK_TEAM / TEAM_MEMBERS个人组/系统组TEAM_ID、MEMBER_ID、TYPE(0系统/1个人/2私人)第一张表 ADDRESSBOOK 里有个容易看走眼的细节ID 是主键但真正关联组织人员的是 MEMBER_ID。做 JOIN 时要用 MEMBER_ID 去关联人员表而不是 ID。如果按 ID 关联查出来的数据要么为空要么错位到另外一个人。我做人员同步时第一次就栽在这里查了半天才发现 ID 和 MEMBER_ID 是两套编号体系。ADDRESSBOOK_MEMBER 是独立于组织架构的外部联系人表字段非常完整COMPANY_NAME、COMPANY_DEPT、COMPANY_LEVEL、COMPANY_POST、COMPANY_PHONE、FAMILY_PHONE、MOBILEPHONE、FAX、ADDRESS、POSTCODE、EMAIL、WEBSITE、BLOG、MSN、QQ、MEMO。CATEGORY_ID 指向联系人类别。要注意的是这张表的 CREATOR_ID 和 CREATOR_NAME 是必填的批量导入外部联系人时这两个字段不带的话INSERT 会直接报错。2.2 70 个扩展字段自定义控件的落库方式ADDRESSBOOK 最值得研究的是 EXT_ATTR_1 到 EXT_ATTR_70一共 70 个扩展字段按类型分成七个区间。这套设计和表单设计器里的自定义控件是一一对应的关系后台新增一个文本框数据落到 EXT_ATTR_1~EXT_ATTR_10 的区间新增一个数字控件落到 EXT_ATTR_11~EXT_ATTR_20。字段注释只写了「文本类型扩展字段 1」「数字类型扩展字段 1」这种通用说明具体哪个控件对应哪个字段号需要结合后台表单设计器里控件的排列顺序来核对。字段区间数据类型语义EXT_ATTR_1 ~ 10VARCHAR(1024)文本类型扩展字段EXT_ATTR_11 ~ 20DECIMAL(19,4)数字类型扩展字段EXT_ATTR_21 ~ 30DATETIME日期类型扩展字段EXT_ATTR_31 ~ 40VARCHAR(50)枚举类型数据字段EXT_ATTR_41 ~ 50VARCHAR(50)选人类型数据字段EXT_ATTR_51 ~ 60VARCHAR(50)选部门类型数据字段EXT_ATTR_61 ~ 70VARCHAR(50)选岗位类型数据字段查询某个人员的扩展信息时SQL 一般这样写SELECT ID, MEMBER_ID, CREATE_DATE, EXT_ATTR_1, -- 文本扩展字段对应表单设计器第 1 个文本框 EXT_ATTR_11, -- 数字扩展字段对应第 1 个数字控件 EXT_ATTR_21, -- 日期扩展字段 EXT_ATTR_31, -- 枚举字段 EXT_ATTR_41, -- 选人控件 EXT_ATTR_51 -- 选部门控件 FROM ADDRESSBOOK WHERE MEMBER_ID 10086;这段 SQL 的逻辑是按 MEMBER_ID 定位人员把七个类型的扩展字段各取一个看实际落库情况。参数说明EXT_ATTR_x 的具体业务含义在字典里查不到字典只告诉你这个坑位是文本、数字、日期还是选人选部门。默认建好的库这些字段绝大多数是 NULL只有后台加了对应控件并填写了值才会有数据。开发自研模块时如果要读人员扩展信息先到表单设计器里数一遍控件顺序再确定具体是哪一列这一步是纯体力活但省不掉。扩展字段用 DECIMAL(19,4) 存数字、VARCHAR(50) 存选人选部门这套设计对系统来说有历史包袱但对二次开发反而是好事不管业务上怎么自定义物理表结构是稳定的SQL 不用跟着表单改来改去。2.3 ADDRESSBOOK_SET查看范围和导出打印权限的落库点ADDRESSBOOK_SET 表控制通讯录的展示逻辑字段不多但每个都是权限相关的开关。VIEW_SCOPE 控制查看范围KEY_INFO 控制关键信息是否展示KEY_INFO_TYPE 区分关键信息类型1-手机号职务级别2-手机号3-职务级别EXPORT_PRINT 控制导出与打印。还有 EXTERNAL_SCOPE 控制编外人员权限1-按工作范围显示2-全部隐藏这个字段在对接集成时经常被忽略导致编外人员数据查得到但界面上看不到。M3_SET 和 ZX_SET 这两个字段值得单独说M3 是移动端应用ZX 是致信。这两个字段表示是否单独设置移动端的通讯录显示字段值为 1 时显示列头走 M3_DISPLAY_COLUMN 或 ZX_DISPLAY_COLUMN而不是通用的 DISPLAY_COLUMN。意思是 PC 端和移动端的通讯录字段展示可以不一样。做移动端 H5 或小程序集成时读显示字段要先判断 M3_SET 的值再决定取哪一列。ADDRESSBOOK_SET_SCOPE 存的是设置项与组织范围的关联关系ADDRESSBOOK_SET_ID 指向设置表主键USER_ID 和 USER_TYPE 指定这个设置作用在哪个组织实体上。它和 ADDRESSBOOK_SET 是典型的一对多关系一个单位可以给不同部门配不同的查看范围。3. 考勤模块ATTENDANCE 系列表的层级关系与统计口径3.1 考勤组、排班、班次、日计划四层结构先理清考勤模块是 V8.1 数据字典里表数量最多的部分核心是四层结构ATTENDANCE_TEAM 考勤组在最上层下面挂 ATTENDANCE_ARRANGE 排班排班下挂 ATTENDANCE_CLASS 班次班次再定义具体的上下班时间 ATTENDANCE_FIX_TIME最后用 ATTENDANCE_DAY 把班次落到一周里的具体星期几。这个层级关系决定了你在哪张表里找数据。查某人属于哪个考勤组先查 ATTENDANCE_AUTH_ENTITYENTITY_TYPE: 3-人员1-部门0-单位找到 ATTENDANCE_TEAM_ID再去 ATTENDANCE_TEAM 拿考勤组名称。ATTENDANCE_TEAM 里的 ORG_ACCOUNT_ID 是单位 IDIS_NEW 标记是否为最新配置START_DATE 和 END_DATE 是生效起止时间。做考勤组迁移时要判断 IS_NEW否则容易把历史配置和当前配置搞混。ATTENDANCE_CLASS 里的 CLASS_TYPE 是班次类型0-1 天 1 次1-1 天 2 次2-1 天 3 次。FLEX_TIME 是弹性时间LATE_SERIOUS 是严重迟到阈值ABSENT_WORK 是旷工阈值。这三个字段的单位是分钟做统计报表时要跟考勤规则里的配置核对不同单位往往不一样。当前的班次时间是针对排班的ATTENDANCE_FIX_TIME 里定义了 WORK_TIME 上班时间、END_TIME 下班时间、EARLY_WORK_TIME 最早签到时间、LAST_END_TIME 最晚签退时间还有上下班提醒开关和提前提醒分钟数。ATTENDANCE_DAY 是日计划表一条记录表示某个排班在某一天WEEK_DAY安排的是哪个班次IS_WORK 标记是否工作日。查询某天某人的班次要用 MEMBER_ID 找到考勤组再通过排班 ID 和星期几找到班次 ID链路比较长建议直接把这个查询做成视图避免每次都要 JOIN 四层。3.2 打卡流水ATTENDANCE_INFO 和 ATTENDANCE_HISTORY 的字段语义打卡数据有两张表ATTENDANCE_INFO 和 ATTENDANCE_HISTORY。从字段差异看INFO 多了 STATE、PUNCH_TYPE、MODIFY_NUM、MAC_ADDRESSHISTORY 没有这些。线上库常见用法是 INFO 存当前生效的打卡记录HISTORY 存每一次打卡的原始流水。我一般以 INFO 为准做查询需要核对原始打卡轨迹时再去对 HISTORY。两张表共用的关键字段SIGN_TIME 打卡时间TYPE 签到来源1-签到2-签退3-外勤STATE 打卡状态3-上班迟到4-下班早退5-正常上班6-正常下班LONGITUDE/LATITUDE 经纬度SIGN 打卡地址或 IP。地址信息做得很细CONTINENT、COUNTRY、PROVINCE、CITY、TOWN、STREET 六级外加 NEAR_ADDRESS 附近地址和 ADDRESS_TYPE1-POI2-街道3-路4-其他。RECEIVE_IDS 是接收人员 ID用逗号分隔也就是打卡后要通知哪些人。SOURCE 字段区分 1-PC、2-移动端做移动端集成的要特别注意。IMG_NUM 和 RECORD_NUM 是图片和语音数量对应打卡附带的拍照或语音说明IMG_INFO 和 RECORD_INFO 存的是 JSON 格式的附件信息不是附件表 ID解析的时候别搞错。SELECT MEMBER_ID, SIGN_TIME, TYPE, -- 1签到 2签退 3外勤 STATE, -- 3迟到 4早退 5正常上班 6正常下班 SIGN, -- 打卡地址或IP LONGITUDE, LATITUDE, SOURCE, -- 1-PC 2-移动端 PUNCH_DATE -- 考勤日做分组统计用 FROM ATTENDANCE_INFO WHERE MEMBER_ID 10086 AND PUNCH_DATE 2025-01-01 AND PUNCH_DATE 2025-02-01 ORDER BY SIGN_TIME;这段 SQL 的逻辑是查某人某月的打卡流水。TYPE 和 STATE 是两套维度TYPE 管签入签出还是外勤STATE 管是否迟到早退。做报表时这两个字段都要用上只取其中一个会把外勤误判成正常出勤。另外 PUNCH_DATE 和 SIGN_TIME 是两个概念PUNCH_DATE 是考勤归属日而不是实际打卡时刻跨天排班的时候尤其要注意凌晨的打卡会归属到前一个工作日。3.3 日统计宽表ATTENDANCE_DAY_STATISTICS 不要自己重算ATTENDANCE_DAY_STATISTICS 是签到日统计表按「人员 考勤日」一条记录汇总全天情况。上午的 AM_START_TIME、AM_END_TIME、AM_START_STATE、AM_END_STATE 和下午的 PM_ 系列一一对应NORMAL_DAY 是正常出勤天数AB_NORMAL_DAY 是异常天数NONWORKDAYS_DAY 是非工作日打卡天数。LATE_NUM、LEAVE_EARLY_NUM、OUTSIDE_NUM、MISSINGCLOCK_COUNT 分别统计迟到、早退、外勤、缺卡次数MISSINGCLOCK_COUNT 又拆成 WORKING_MISSINGCLOCK 上班缺卡和 KNOCKOFF_MISSINGCLOCK 下班缺卡。这张表是预计算好的宽表统计月度考勤时直接 SUM 对应字段就行。常见做法是SELECT MEMBER_ID, SUM(LATE_NUM) AS total_late, SUM(LEAVE_EARLY_NUM) AS total_leave_early, SUM(MISSINGCLOCK_COUNT) AS total_missing, SUM(NORMAL_DAY) AS normal_days, SUM(AB_NORMAL_DAY) AS abnormal_days FROM ATTENDANCE_DAY_STATISTICS WHERE ACCOUNT_ID ? AND PUNCH_DATE 2025-01-01 AND PUNCH_DATE 2025-02-01 GROUP BY MEMBER_ID;这段 SQL 的逻辑是按人员汇总一个月的出勤指标。注意这里直接用了 ACCOUNT_ID 过滤单位跨单位统计时要去掉这个条件。参数说明LATE_NUM、LEAVE_EARLY_NUM 这些字段类型是 SMALLINT单日最大值不会超过 127做汇总时用 INT 接收即可。PUNCH_CLASS 字段标记当天应打卡次数1 或 2缺卡数计算依赖这个值应打 2 次只打了 1 次MISSINGCLOCK_COUNT 才会正确置位。一个重要的边界别用 ATTENDANCE_HISTORY 自己重算迟到早退。HISTORY 是原始流水没有排班规则和弹性时间的上下文重算的结果和系统统计几乎必然对不上。统计口径以 ATTENDANCE_DAY_STATISTICS 为准需要明细再去查流水。4. 代理设置与 AI 自动化AGENT、AI_ 系列表的功能定位4.1 AGENT 主表代理期限、取消标记、类型区分AGENT 是代理设置应用表控制「谁替谁处理待办」。AGENT_ID 是代理人 IDAGENT_TO_ID 是被代理人 ID这两个字段在字典里注释都标了但很多人会相互搞反。我处理过一张错误报表统计代理工作量时把 AGENT_ID 当成被代理人整张表数据全部反了。AGENT_TYPE 区分 1-代理设置和 2-离职交接这个字段决定业务逻辑完全不一样代理设置是主动授权离职交接是被动接管。做数据清理时离职交接的记录不能随便删涉及历史待办归属。AGENT_OPERATION 标记操作类型0-被代理人自己1-集团管理员2-单位管理员。CANCEL_FLAG 是取消标记0-未取消1-已取消查有效代理时一定要加 CANCEL_FLAG 0 的条件否则会把历史已取消的代理算进去。START_DATE 和 END_DATE 是代理期限CANCEL_DATE 记录取消时间。HAS_AWAKE 字段注释写了「未使用」这就是历史字段的典型代表别去给它赋予业务含义。AGENT_REMIND 和 AGENT_TO_REMIND 分别是代理人和被代理人的提醒开关。MATTER_TYPE 是事项条件设置类型0-按处理人设置1-按发起人设置默认 1。这个字段影响代理规则的匹配方式按发起人设置意味着代理只在特定发起人的事项上生效按处理人设置则反之。4.2 AGENT_DETAIL 与 AGENT_SCOPE代理哪些应用、覆盖哪些人AGENT_DETAIL 是代理详细表字段很简单AGENT_ID 对应 AGENT 主表APP 是应用 IDENTITY_ID 是实体 ID。含义是一条代理记录可以针对多个应用分别设置APP 表示这个代理规则在哪个应用下生效。做待办接入时如果发现某个应用下的代理没生效先查 AGENT_DETAIL 里有没有对应 APP 的记录。AGENT_SCOPE 存储代理设置中发起人的范围。IDENTITY_TYPE 存实体类型如 ACCOUNT、DEPARTMENTENTITY_ID 对应该类型下的具体 ID。这张表回答的问题是「这个代理规则对哪些发起人有效」。注意它和 AGENT_DETAIL 是不同维度AGENT_DETAIL 管应用范围AGENT_SCOPE 管发起人范围两者是 AND 关系一条代理规则要同时匹配应用和发起人才会触发。4.3 AI_ 系列V8.1 的智能审批条件不是黑匣子字典里 AI_ 开头的表一共有五张分别是 AI_DEAL_CONDITION、AI_ORG_CHANGE_RECORD、AI_ORG_MEMBER_CHANGE、AI_PROCESSING_CONDITION、AI_REMIND_RECORD 和 AI_REMIND_COUNT。这批表说明 V8.1 的 AI 能力不是黑匣子处理条件全部落库可查。AI_DEAL_CONDITION 是核心TEMPLATE_ID 关联模板SENDER_ID 发起人USER_ID 处理人DEAL_TYPE 定义操作类型0-回退1-指定回退2-撤销3-终止4-不同意5-处理时长。SIGNLE_VIEW_PERIOD 是处理时长限制默认为 0。做审批时效报表时处理时长的规则从这里取而不是写死在代码里。AI_PROCESSING_CONDITION 是模板级别的自动处理条件CONDITION_VALUE 是长文本字段存的是条件表达式。AI_REMIND_RECORD 记录催办行为REMIND_USER_ID 催办人REMIND_AFFAIR_ID 被查看的事项COUNT 查看次数IS_SEND_MSG 是否已发送提醒消息。AI_REMIND_COUNT 是被催办方的视角AFFAIR_ID 被催办事项AFFAIR_RECEIVE_TIME 接收时间COUNT 收到催办的次数。AI_ORG_CHANGE_RECORD 和 AI_ORG_MEMBER_CHANGE 是组织变更审计表记录部门、岗位、职务级别的变更以及人员在这些维度上的调动。OLD_ID/OLD_VALUE、NEW_ID/NEW_VALUE 一一对应ORG_TYPE 标记类别0-部门1-岗位2-职务级别。这类表对追溯组织历史非常有用比如要查某人三个月前属于哪个部门就要靠 AI_ORG_MEMBER_CHANGE 来还原因为当前组织表里已经是新值了。提示AI_ORG_MEMBER_CHANGE 只记录有变更的维度没变的维度是 NULL查历史快照时要对 OLD_DEPT_ID、OLD_POST_ID、OLD_LEVEL_ID 分别做 IS NOT NULL 判断不能整行直接覆盖。5. 避坑数据字典使用中的五个边界问题5.1 通讯录关联字段用错查出来永远错位现象按 ID 关联人员表查出来的姓名和实际人员对不上。原因ADDRESSBOOK 表里 ID 是主键但真正关联组织人员的是 MEMBER_ID两套编号体系不通用。解决所有和人员表的 JOIN 统一用 MEMBER_ID。拿数据字典建视图时先确认哪个字段是业务外键不要看到主键就直接用。5.2 界面上有值的扩展字段库里查出来是空现象后台表单设计器里配置了人员扩展信息界面上显示正常直接查 ADDRESSBOOK 对应的 EXT_ATTR_x 却是 NULL。原因扩展字段控件的落库位置不一定在 ADDRESSBOOK。表单设计器里的控件可以绑定不同数据源有些落在业务表单表有些落在人员扩展表字典里 EXT_ATTR 注释没有业务含义不好判断。解决先确认控件绑定的数据源类型。我用过一个土办法在界面上填一个特征明显的值如 12345TEST保存后全表扫一遍哪个字段出现这个值就能确定落库位置。5.3 删除代理记录报外键错误现象DELETE FROM AGENT WHERE ID ?数据库报外键约束错误删不掉。原因AGENT_DETAIL 和 AGENT_SCOPE 都有 AGENT_ID 外键指向 AGENT 主表直接删主表违反约束。解决按顺序先删子表再删主表DELETE FROM AGENT_SCOPE WHERE AGENT_ID ?; DELETE FROM AGENT_DETAIL WHERE AGENT_ID ?; DELETE FROM AGENT WHERE ID ?;这三条语句的逻辑是处理主外键关系。AGENT_SCOPE 和 AGENT_DETAIL 都依赖 AGENT 主表必须等子表删完才能删主表。如果系统有离职交接数据AGENT_TYPE2建议先查一遍 AGENT_DETAIL 确认没有正在生效的代理再做清理。5.4 考勤统计数字和系统对不上现象自己拿 ATTENDANCE_HISTORY 统计迟到次数和考勤报表里显示的数字不一致。原因HISTORY 是原始流水最终状态经过补卡、排班规则、弹性时间等多层处理后提前在修饰时已经改动了。比如弹性时间内的迟到会被记为正常但原始流水里还是迟到。解决月度统计一律以 ATTENDANCE_DAY_STATISTICS 的 LATE_NUM、LEAVE_EARLY_NUM 等预计算字段为准。明细对账时用 INFO 表的状态字段STATE3 迟到4 早退做过滤不要用 HISTORY 重算。5.5 UPDATE_DATE 不更新时间戳字段不是每个都可靠现象线下环境测试改了 ADDRESSBOOK 的 MEMBER_ID 对应的记录后UPDATE_DATE 还是旧值。原因部分表的 UPDATE_DATE 字段设计了但没有写更新逻辑应用层只做 INSERT 不动 UPDATE。解决依赖变更时间时先确认该表是否有对应的业务时间字段。例如 BBS_ARTICLE 用 MODIFY_TIME 记录修改时间ATTENDANCE_DAY_STATISTICS 用 MODIFY_TIME而 AGENT 用 CANCEL_DATE 记录取消时间。线上对数据字典时把每个表的时间字段列一份对照清单哪个可用哪个是摆设测试一遍就知道了。6. 把数据字典变成自己的元数据查询工具导入、建表、反查6.1 数据字典转成可查询的元数据表原始数据字典是文本格式直接翻效率太低。我的做法是先把字典转成二列表格表名、字段名、字段类型、是否必填、注释然后导入一张元数据表。这样字典就从 PDF/文档变成了可查询的索引。CREATE TABLE DICT_IMPORT ( TABLE_NAME VARCHAR(64) NOT NULL, COLUMN_NAME VARCHAR(64) NOT NULL, COLUMN_TYPE VARCHAR(64), IS_PK INT, COLUMN_COMMENT VARCHAR(255) );表结构说明TABLE_NAME 存表名COLUMN_NAME 存字段名COLUMN_TYPE 存数据类型IS_PK 标记是否主键COLUMN_COMMENT 存注释。导入完成后所有查询都可以在这张表上做。6.2 按注释反查表不知道表在哪也能找字段做二次开发时最常见的场景业务方说「我要查人员编号」但不知道字段在哪个表。这时用 LIKE 查注释最省事SELECT TABLE_NAME, COLUMN_NAME, COLUMN_COMMENT FROM DICT_IMPORT WHERE COLUMN_COMMENT LIKE %迟到% ORDER BY TABLE_NAME;从结果能看到「迟到」相关的字段分布在 ATTENDANCE_DAY_STATISTICSLATE_NUM、ATTENDANCE_INFOSTATE等多张表里具体用哪张再结合业务场景判断。用 LIKE 反查注释还有一个好处能发现字典里相同含义的字段在不同的表里命名不一致的情况比如 MODIFY_TIME 和 UPDATE_DATE 都表示最后修改时间但分布在不同模块写 SQL 前先统一认识避免 JOIN 匹配错列。6.3 字典和线上库对一遍形成排障习惯每次对接新模块我先跑一遍这个验证SELECT TABLE_NAME, COLUMN_NAME, COLUMN_TYPE FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA 你的库名 AND TABLE_NAME ADDRESSBOOK;把 information_schema 的结果和数据字典逐字段比对确认类型一致、字段存在、注释对得上。这套流程我已经固定为动作拿到任何新模块先建 DICT_IMPORT再和线上 information_schema 做全量比对最后把差异整理成一张「坑位清单」列出哪些字段有值、哪些字段是摆设、哪些历史字段已经废弃。从那以后每次改表单或写集成 SQL我都强制先走一遍这套流程再动手写查询。数据字典就像一张地图信息全在里面关键在于你愿不愿意花半天时间把它变成自己的查询索引。希望帮到你。本文还有配套的精品资源点击获取