简介面向医院信息化运维与二次开发人员的HIS数据库表结构说明文档用于解决初接手天健系统时表名陌生、字段含义不清、字典表与业务表难以对应的问题。文档按公共部分、人员属性、国家地区单位属性、科室字典、医疗工作、疾病诊断与医疗操作等模块组织逐表列出英文表名、字段含义与状态标识并保留版本更新记录及红蓝黑字体的使用状态区分。读者可把它当作查阅性别、婚姻、民族、费别、病人来源等字典表及主干业务表的案头索引也可据表间对应关系梳理临床科室配置、合同单位与病案管理等环节。资源包共1个doc文件约7.19MB为单册完整手册便于离线检索和打印对照。目前已有852人学习下载对需要摸清天健HIS数据结构、编写查询语句或做接口对接的工程师较有参考价值。1. 拿到一套老 HIS 的库为什么先翻这份 17 章的数据字典前阵子帮一位同行看一套跑了十几年的医院信息系统数据库几百张表字段名是拼音首字母和英文缩写混着写的注释基本没有。业务方要一份「门诊退费月度明细」我在库里摸了两个小时才确认钱记在门诊收据主记录和支付方式记录两张表上而且退费到底是负数冲正还是另起一条记录还得回头去看结算操作类型字典。这种活儿卡住的往往不是 SQL 水平而是缺一张字段级的地图。这份 HIS 数据结构手册就是那张地图从 1996 年第 4 稿一路改到 2006 年第 15 稿覆盖 17 个模块、上千张表每张表给出中文名、英文表名、字段含义和使用状态。它服务的是要对接接口、做数据迁移、写报表、排查对账差异的工程师不必通读按模块查。2. 拆骨架17 个模块、四层表结构怎么排布第一次翻开目录的人容易犯一个错把它当成一张平铺的表清单从上往下顺着看。看到第四十几页就迷路了因为「疾病字典」「手术操作字典」「检验项目字典」这些名字太像看不出谁依赖谁。真正省时间的读法是先把 17 个一级模块归类再在每一类里认清四层结构最后才去抠具体字段。2.1 从字典到流水四层结构决定了查询顺序手册里的表粗分四层这四层不是文档作者刻意设计的而是那套系统十几年迭代下来自然沉淀的结果。第一层是字典层性别、婚姻状况、民族、血型、职业分类、身份、费别、病人来源、入院方式、出院方式、病情状态这些表都在公共部分编号 1.x。它们只干一件事把业务里有限的可选值编码化。这一层的特点是表多、字段少、变动慢一张表往往只有编码、名称、有效标志三四个字段但被全库几十张业务表引用。第二层是主记录层病人主索引、住院主记录、就诊记录、门诊挂号记录、检查主记录、检验主记录都属于这一层。它们代表一个业务对象的「头」一条主记录对应现实世界里的一件事一个病人建档、一次住院、一次就诊、一次检查。主记录层的表通常有唯一主键比如病人标识号、就诊序号、检查号这些主键是后面所有明细挂靠的锚点。第三层是明细层处方明细、检查项目、检验项目、医嘱计价项目、费用记录都在这里。明细层的行数最多一张住院主记录可能对应几百条医嘱明细一张门诊收据对应十几条费用明细。明细层靠「主键 序号」和主记录层关联序号在有些表里叫 ITEM_NO在有些表里叫 ORDER_SUB_NO命名并不统一。第四层是流水和日志层病人入出转日志、病案追踪日志、药品调价记录、发票重打日志、主索引合并记录都属于这一层。这一层的表只追加不修改用来还原「什么时候发生了什么」做审计和对账时绕不开但日常报表很少直接查。提示搞清楚一张表属于哪一层比记住它的字段更有用。字典层的表可以放心 JOIN流水层的表 JOIN 之前先想清楚数据量。2.2 版本标注与三种使用状态红字、蓝字、黑字的意思手册开头有一段说明很多人扫一眼就跳过了恰恰是这段说明决定了你后面所有的判断。它规定了三种颜色标注红字标识的表和字段表示未使用状态蓝字标识的是新增且在用的黑字标识的是在用状态。这条约定贯穿整本手册包括目录页。这意味着两件事。第一目录里出现的表名不等于这张表现在还在跑有些表从 1.0 版就写进去了到第 15 稿还留在目录里只是标了红。第二判断一张表能不能用不能只看它在不在目录里要看它在正文里的颜色标注和括号备注。手册里大量表名后面直接跟了括号说明比如「不使用」「新增」「已过时」这些括号比颜色更可靠因为打印或转存成纯文本时颜色会丢失括号不会。我在实际项目里的做法是先把目录导出成一份清单逐行把括号备注抽出来做成一个状态列取值就三种——在用、新增、不使用。这份清单放在手边后面写任何一条 SQL 之前先查一下能省掉大量「查了半天发现是空表」的时间。这套标注体系还有一个副作用值得注意。手册的更新记录显示第 12 稿到第 15 稿之间做过两次「全新整理」整理者不是同一个人标注风格因此不完全一致。早期的表更倾向于用红字标未使用后期整理的部分更倾向于用括号备注。所以遇到颜色和括号冲突的情况以括号为准这是血泪经验。2.3 十七个模块的依赖顺序与体量对照把 17 个模块按依赖关系排一下读起来会顺很多。公共部分和人员属性在最前面因为它们被几乎所有模块引用国家地区单位和科室字典紧随其后科室字典是全院数据的分组基准医疗工作、疾病诊断与医疗操作、药品物资、费用这四个模块是「基础语汇」定义了系统里能开什么医嘱、能收什么费病案、门诊病人管理、门诊医生、住院病人管理、医嘱、检查、检验、药品管理、门诊收费这九个模块是「业务流程」每一个都同时引用前面所有的基础语汇。模块编号段定位读的时候关注什么公共部分人员属性1.x字典层编码规则、有效标志国家地区单位及科室2.x字典层科室多属性拆表医疗工作3.x字典层号别、床位、病案状态疾病诊断与医疗操作4.x字典层诊疗项目与价表对照药品物资5.x字典层药品编码、供应商、货位费用6.x字典 规则价表、收费系数、模板系统维护7.x元数据表字段解释、权限输入法8.x工具编码规则可跳过病案9.x主记录层病人主索引是核心门诊病人管理10.x主记录 流水号表、预约、结帐门诊医生11.x明细层门诊医嘱三张表住院病人管理12.x主记录层床位、在院、转科医嘱13.x明细层医嘱三段式检查14.x主记录 明细预约、报告、图像索引检验15.x主记录 明细仪器配置、结果对照药品管理16.x明细 流水出入库、盘点、摆药门诊收费17.x流水层收据、支付方式这张表不是让你背是让你在拿到一个新需求时能快速定位该翻哪几章。比如要做「住院病人日均费用」起点在 12 章的住院病人记录中间经过 13 章的医嘱和医嘱计价项目落到 9 章的住院病人费用记录三章搞定。要是不知道这个路径很容易一头扎进 6 章的价表里出不来。还有一点模块编号不代表重要程度也不代表使用频率。8 章输入法整个模块跟业务数据没关系做数据集成的可以直接跳过7 章系统维护里的几张元数据表反而值得早看后面第 6 章会讲到怎么用它们反推全库关系。3. 吃透字典表把 SEX_DICT 这类代码翻译成人话的三步字典表是这套库里最不起眼、也最容易埋雷的部分。它们字段少看起来一目了然但你只要写过一条带字典翻译的报表 SQL就会知道坑有多密编码列名不统一、有效标志含义不明、同一张字典在手册里出现两次、某些字典的编码是字符串而不是数字。这一章把字典表的读法拆成三步每一步都对应一个具体的坑。3.1 编码列与名称列为什么不统一怎么应对字典表的经典形态是两个业务列一个编码列、一个名称列加一个有效标志。以性别字典为例编码可能是「1/2/9」也可能是「M/F/U」名称列是「男/女/未知」。手册里给出的字段清单会明确写出哪一列是编码、哪一列是名称但不同字典的列名并不统一有的叫 CODE有的叫 ID有的直接把业务含义写进列名比如 SEX_CODE。为什么不统一因为这批表是不同年代、不同分系统负责人分别设计的早期没有强制的命名规范后期整理时出于兼容考虑没有改名。这不是设计缺陷是历史成本。对使用者的影响是你不能靠猜列名写 SQL必须逐张表翻手册的字段清单。我一般会做一张「字典表列名映射表」两列就够表名、编码列名。遇到新字典就补一行。有了这张映射表写翻译 SQL 时可以批量套模板不用每张表都去翻一遍。这张映射表的初始版本可以从手册的字段清单里一次性抽出来抽法在第 6 章给脚本。除了编码列和名称列字典表通常还有几个公共字段有效标志、排序号、备注。有效标志是最需要小心处理的因为不同字典对「停用」的表达方式不一样有的用 0/1有的用 Y/N有的用一个日期字段表示停用时间。做报表时如果不过滤停用项会统计出一批早就废弃的费别或科室。3.2 对照表与属性拆表科室为什么要拆成五张表手册第 2 章有一组表特别能说明这套库的设计思路科室字典、临床科室配置情况、临床科室与病房对照、科室临床属性字典、科室门诊住院属性字典、科室内外科属性字典。一个「科室」被拆成了六张表。直觉上这是过度设计一张宽表加几个字段就能解决。但放在医院场景里拆开是有道理的。科室的「临床属性」「门诊住院属性」「内外科属性」是三个独立的分类维度每个维度的取值集合不同而且会随着医院管理口径变化而增删。如果做成宽表每加一个维度就要改表结构改表结构就要停机停机就要协调全院。拆成一对一的属性表之后加一个新维度只是加一张新表老代码完全不受影响。同样的思路出现在费别上费别字典管「有哪些费别」费别与身份对照关系管「某费别下允许哪些身份」两张表分开。做医保或公费医疗相关的报表时这个对照关系是必须 JOIN 的否则会把不适用该费别的病人算进去。表作用关联键科室字典科室基础信息科室编码临床科室配置情况是否是临床科室、床位等配置科室编码临床科室与病房对照科室与病区的多对多关系科室编码 病区科室临床属性字典临床属性取值集合属性编码科室门诊住院属性字典门诊/住院属性取值集合属性编码科室内外科属性字典内外科属性取值集合属性编码实务上的建议是不要试图把这些表「合并简化」成一张视图然后到处用。视图里的 JOIN 会在数据量大时变成性能瓶颈而且一旦某个维度出现一对多比如一个科室对应多个病区视图就会扇出行数翻倍你算的床位数就不对了。3.3 一条翻译 SQL 的写法与三个参数下面这条 SQL 是字典翻译的通用模板拿病人主索引举例把性别、费别、身份三个代码列翻译成中文。-- 病人主索引的字典翻译模板 -- 说明编码列名以手册字段清单为准这里按常见命名书写 SELECT p.PATIENT_ID AS 病人标识号, p.NAME AS 姓名, p.SEX AS 性别编码, s.SEX_NAME AS 性别, p.CHARGE_TYPE AS 费别编码, c.CHARGE_TYPE_NAME AS 费别, p.IDENTITY AS 身份编码, i.IDENTITY_NAME AS 身份 FROM PAT_MASTER_INDEX p LEFT JOIN SEX_DICT s ON s.SEX_CODE p.SEX AND s.VALID_FLAG 1 -- 只取有效字典项 LEFT JOIN CHARGE_TYPE_DICT c ON c.CHARGE_TYPE_CODE p.CHARGE_TYPE AND c.VALID_FLAG 1 LEFT JOIN IDENTITY_DICT i ON i.IDENTITY_CODE p.IDENTITY AND i.VALID_FLAG 1;三个地方值得展开。第一全部用 LEFT JOIN 而不是 INNER JOIN。字典表里可能缺项比如某个历史病人存了一个早已删除的费别编码用 INNER JOIN 会让这条病人在报表里凭空消失这种「数据丢了但没人报错」的问题最难查。第二有效标志的过滤条件写在 ON 子句里而不是 WHERE 子句里写进 WHERE 会把 LEFT JOIN 退化成 INNER JOIN前功尽弃。第三字段别名用中文方便直接把结果贴给业务方看省一轮解释。还有个小细节如果某张字典表的编码列是变长字符串JOIN 之前要确认两边字符集和长度一致否则在某些库上会走不了索引几百万人次的病人主索引扫起来很慢。这种情况我一般会先 EXPLAIN 看一眼执行计划再决定要不要加函数索引。4. 串主线PAT_MASTER_INDEX 到 ORDERS_COSTS 的四个连接点字典表解决的是「值是什么意思」主线表解决的是「事情怎么连起来」。这套库里所有的业务数据最终都能追到一个人身上从病人建档那一刻起后面每一次就诊、每一条医嘱、每一笔费用都是这条主线的分支。把四个连接点搞清楚剩下的表基本都是这四个点的变体。4.1 病人主索引是唯一刚性约束病人主索引是整份手册里最该先看的表。它记录的是「这个人在系统里是谁」主键是病人标识号一旦生成就不该变。手册第 9 章把它放在病案模块的第一张位置本身就说明了分量。这张表的几个关键字段需要理解到位。病人标识号是全院唯一的门诊、住院、检查、检验全都引用它。姓名之外通常还有拼音码和五笔码之类的检索码用于快速定位。身份信息、费别、出生日期这些属性在建档时确定后续可能被修改所以主索引通常会配套一张修改姓名记录表把变更留痕。主索引还有一个容易被忽略的机制合并。同一个病人在门诊和住院分别建了档或者因为姓名录入差异建了两次就需要合并。手册里有主索引合并记录表记录哪两条主索引被合并、合并时间、操作人。做数据迁移或者历史数据清洗时这张表必须查否则会把同一个人算成两个人门诊量和住院量都会虚高。实务上我一般会先跑一条简单查询看主索引里病人标识号的格式和长度分布确认是否存在多种编码规则混用。老系统迁移过来的数据经常出现这种情况比如早期是顺序号后期改成了带年份前缀的号两种混在一张表里。不先摸清楚后面所有的关联都可能差一位。4.2 门诊与住院两条线的分叉和汇合病人主索引往下走立刻分成两条线。住院线的主记录是病人住院主记录一次住院一条主键是病人标识号加就诊序号。住院主记录里有入院日期时间、入科科室、出院日期时间、出院方式、住院天数这些字段是住院报表的基础。再往下是在科记录记录病人在住院期间每一次转科一次住院可能对应多条在科记录做科室工作量统计时必须用这张表而不是住院主记录上的入科科室否则转科病人的工作量会全部算给首科。门诊线的主记录是就诊记录一次就诊一条主键是病人标识号加就诊序号或者就诊流水号。门诊还有一层挂号层面的记录挂号号表、预约记录、号别定义这些表描述的是「号源怎么放出去」就诊记录描述的是「病人实际来了没有」。这两层经常被混淆做门诊量统计时用的是就诊记录做号源利用率统计时用的是号表和预约记录。两条线在诊断和费用上汇合。诊断记录和门诊诊断记录是两张表一张对应住院、一张对应门诊字段结构相似但不要混用。费用同理住院病人费用记录和门诊收据主记录是两套。这个分叉结构决定了一个常见需求「病人全病程费用」必须写 UNION不能指望一张表查完。4.3 医嘱的三段式主记录、计价、执行医嘱模块是整份手册里设计最讲究的部分三张表分工明确医嘱表存医嘱本身医嘱计价项目表存这条医嘱对应的收费项医嘱执行表存护士实际执行的动作和时间。这么拆的原因很实际。一条医嘱可能对应零个、一个或多个计价项目。比如「一级护理」对应一条护理费「静脉输液」可能对应输液费加一次性耗材费两条。如果计价项目塞进医嘱表的字段里就没法表达一对多。执行表同理一条长期医嘱每天执行多次每次执行都要留痕只能独立成表。三张表的连接键是病人标识号、就诊序号、医嘱序号计价和执行表通常还有子序号。这里有个坑医嘱序号在不同表里的唯一性范围不一样。有的系统里医嘱序号是住院内唯一有的是病人内唯一有的是全库唯一。手册会在字段说明里写清楚但很容易看漏。写关联之前先确认这一点否则会把别的病人的医嘱关联进来。-- 住院病人从住院主记录到医嘱计价的完整链路 SELECT v.PATIENT_ID AS 病人标识号, v.VISIT_ID AS 就诊序号, v.DEPT_ADMISSION_TO AS 入科科室, o.ORDER_NO AS 医嘱序号, o.ORDER_TEXT AS 医嘱内容, o.START_DATE_TIME AS 开始时间, oc.ITEM_CLASS AS 计价项目类别, oc.ITEM_CODE AS 计价项目代码, oc.AMOUNT AS 数量, oc.COSTS AS 金额 FROM PAT_VISIT v JOIN ORDERS o ON o.PATIENT_ID v.PATIENT_ID AND o.VISIT_ID v.VISIT_ID JOIN ORDERS_COSTS oc ON oc.PATIENT_ID o.PATIENT_ID AND oc.VISIT_ID o.VISIT_ID AND oc.ORDER_NO o.ORDER_NO WHERE v.DISCHARGE_DATE_TIME DATE 2024-01-01 AND v.DISCHARGE_DATE_TIME DATE 2024-02-01;这条 SQL 里日期范围条件加在住院主记录上而不是医嘱上是因为出院的定义在住院主记录用医嘱时间过滤会把跨月住院的病人切碎。金额字段在不同版本里可能叫 COSTS、CHARGE 或 TOTAL_AMOUNT以手册字段清单为准。另外如果一条医嘱被作废通常会有作废标志或者独立的作废记录报表里要过滤掉不然金额会重复计算——这是对账差异最常见的一个来源。4.4 从医嘱到收据对账链路怎么走业务方问「这个月住院收入多少」答案可能来自三个不同的口径医嘱计价汇总、住院病人费用记录汇总、财务收据汇总。三个数经常对不上不是数据错了是口径不同。医嘱计价是「医生开了什么」费用记录是「病人账上记了什么」收据是「实际收了多少钱」。中间还隔着一层结算结算操作类型字典定义了登记、结算、退费、冲正这些动作。做对账报表时我一般会按这三层分别汇总做成一张三列的对照表差异行标出来再逐条查。差异原因通常是三类医嘱开了但没执行、执行了但没计价、计价了但结算时被减免。这三类在手册里都能找到对应的表和字段前提是你知道去哪一章翻。5. 避坑这份手册里五处最容易读错的标注手册本身写得不算含糊问题出在它是一份跨越十年、多人整理、面向纸质打印的文档。有些信息在纸上很清楚转成电子版或者被二手引用之后就变味了。下面五条是我在实际使用中反复踩到的每条按现象、原因、解决写。5.1 红字不等于重点红字等于别用现象有人拿到手册的彩色版看到某些表和字段是红字第一反应是「这是重点标注」于是优先去研究这些表甚至照着红字字段建了新表。原因手册开头的说明写得很清楚红字标识的是未使用状态。这个约定跟大多数技术文档里「红色表示强调」的直觉相反加上很多人习惯跳过前言误读几乎是必然的。解决把颜色和括号备注当作同一套状态标记来读遇到红字先看括号里有没有「不使用」或「已过时」。如果拿到的是黑白打印版或纯文本版颜色信息完全丢失就只能靠括号判断。我的做法是在自己的笔记里给每张表加一个状态列红字表单独归到一个「历史遗留」分区写 SQL 时默认不碰。5.2 同名表在手册里出现两次不代表有两张表现象翻目录时会看到门诊病历记录在 11.1 和 11.2 各出现一次公费用药目录在 5.4 和 5.31 各出现一次队列序号记录表在 10.25 和 11.21 各出现一次。有人据此认为系统里存在两张同名表或者以为是两个不同版本建表时建了两份。原因这是整理过程中的重复条目。第 15 稿做过一次全新整理整理时新增的条目没有和原有条目做去重尤其是跨模块引用的表容易在多个模块下各登记一次。手册是人工编排的这类重复在几百页的文档里很难完全避免。解决以正文里的字段清单为准同一张表名出现多次时比对字段清单是否完全一致。如果一致就是同一张表选编号靠前的那一处作为主引用。如果不一致才需要警惕可能是同名不同结构的遗留表这种情况必须去实际库里核对表结构不能只信文档。5.3 带定制后缀的表不是通用结构现象手册里有若干表在中文名后面标注了定制说明还有些表名本身就带着明显的项目痕迹。有人在通用项目里直接引用了这些表上线后发现是空表或者结构对不上。原因这套系统在不同机构落地时会做本地化改造改造产生的表被一并收进了手册。这些表的存在与否取决于具体部署不是产品标准结构。解决把所有带定制标注的表列成一张单独的清单明确标注「非通用」。做跨机构的数据集成或者产品化交付时默认不依赖这些表需要用时先确认目标环境里是否存在。这条经验值不少时间——我曾经按定制表写了一版接口换一家部署环境直接报错回头重写花了三天。5.4 拼音缩写和英文混用别按字面猜字段含义现象字段名里既有纯英文缩写也有拼音首字母组合还有一些看起来像英文其实是拼音的词。凭字面猜含义猜错的概率不低。原因这套库始建于上世纪九十年代中期参与设计的人员背景不同命名习惯自然不同。后期整理时出于兼容考虑没有统一改名手册的字段说明成了唯一权威的解释来源。解决凡是不确定的字段一律翻手册的字段清单不要靠命名推断。我一般会在项目初期花半天时间把常用表的所有字段和中文含义导成一张对照表后面写 SQL 时直接查这张表。这半天投入的回报率高得离谱尤其是做数据血缘分析的时候。5.5 带 _T 后缀的表不是历史表是队列表现象看到带 _T 后缀的表直觉会认为是「temp」或者「历史备份」于是当成可以忽略的辅助表。原因在这套库的命名习惯里_T 后缀大量用于表示队列或临时中转比如门诊医嘱主记录的队列表、处方医嘱队列表。这些表是门诊医生站和收费、药房之间的异步缓冲数据是活的不是死的。解决判断一张 _T 表要不要处理看两点一是有没有对应的清理机制二是业务上是否有异步流程经过它。做实时性要求高的报表时如果只查主表不查队列表会漏掉刚开出还没落地的数据。反过来做历史统计时如果误查了队列表会因为数据被清理而低估。这两种错我都犯过。6. 反推全库关系用元数据表把上千张表还原成一张图手册第 7 章系统维护里有几张表值得单独拿出来说简易字典代码、字典信息、表字段解释说明、表角色解释说明、表同义词解释说明。这几张表是这套库的「自描述」部分存的是表和字段的元信息。它们的价值在于你可以用它们反向校验手册本身——手册说的和库里存的对不对得上一比就知道。我一般的做法是分两步。第一步从手册目录页抽出表清单生成一份基准文件。import re, csv # 目录行形如9.1 病人主索引 PAT_MASTER_INDEX 78 # 分组章节号 / 中文表名 / 英文表名 / 页码页码可能缺失或与表名粘连 LINE_RE re.compile( r^\s*(\d\.\d)\s # 章节号 r(.?)\s # 中文表名 r([A-Z][A-Z0-9_]{2,}) # 英文表名 r(\d)?\s*$ # 页码 ) rows [] with open(dsm_toc.txt, encodingutf-8) as f: for line in f: m LINE_RE.match(line.rstrip(\n)) if not m: continue # 目录里的非表行直接跳过 sec, cn, en, page m.groups() rows.append({ section: sec, cn_name: cn.strip(), table_name: en, page: page or }) with open(table_index.csv, w, newline, encodingutf-8-sig) as f: w csv.DictWriter(f, fieldnames[section, cn_name, table_name, page]) w.writeheader() w.writerows(rows) print(len(rows), tables parsed)用之前有两个准备动作把手册目录页复制成纯文本存为 dsm_toc.txt每行一条再把目录里带括号备注的行单独处理因为括号内容会被中文表名的非贪婪匹配吃掉一部分。跑完之后会得到一个带章节号、中文名、英文名的 CSV行数应该和手册目录条目数量对得上对不上就说明有行没匹配上回去看是哪几行格式特殊。第二步把这个 CSV 和库里的元数据表做比对。查字典信息表和表字段解释说明表拿到库里实际存在的表名清单和 CSV 做差集。差集里通常有三类手册里有但库里没有的没部署这个模块、库里有但手册里没有的本地新增表、两边都有但字段数不一致的版本不同步。这三类分别对应三种处理方式前两类可以直接标注第三类需要人工核对因为字段数不一致往往意味着本地做过结构改造。比对结果含义处理方式手册有、库无模块未部署或表已下线标注跳过不纳入模型库有、手册无本地定制或后期新增单独建模问清业务含义两边都有、字段数不符版本不一致或本地改造逐字段核对以库为准顺带一提这个 CSV 还能直接喂给绘图工具生成 ER 图的骨架虽然拿不到外键关系但把表按章节分组、按模块上色一张模块级的关系概览图半小时就能出来拿去跟业务方对齐口径特别有效。从那以后我每次接手一套没有文档的老库都会先做一遍「手册清单 vs 库内元数据」的差集再动手写任何一条 SQL。这个习惯让我少走了太多弯路——文档再旧它记录的字段含义仍然是最接近真相的那份材料前提是你知道它哪里不准。希望帮到你。本文还有配套的精品资源点击获取