简介：联众电子病历表结构文档是一份面向ZJHIS、EMR3、EMR及EMRJK用户的电子病历系统数据库表结构说明，适合医院信息化人员、HIS/EMR实施运维工程师阅读。资源为单个doc文件，压缩包大小6.07MB，内容由占贵顺、葛向东多次修订，覆盖用户信息、系统信息、公用医院标识、公用代码、病人类别、病人性质、科室代码、病区代码、系统参数、职工信息等十余类核心表结构。通过逐一拆解各表的字段含义与用途，可帮助读者快速厘清电子病历数据存储关系，支撑日常数据维护、二次开发与统计分析；文档还保留了2011—2012年的修订记录及医生分组、医疗收费、婴儿登记等扩展表，便于完整理解系统演进与数据结构全貌。已有349人浏览学习，对需要理解联众电子病历库表结构或开展医院信息化项目的人员具有较高参考价值。
1. 一份电子病历表结构文档为什么值得你逐字段去抠
做 HIS 或 EMR 相关项目的人，多半都经历过这种场景：系统要对接电子病历，厂商甩过来一个 .doc，说是表结构文档，打开一看几百页，光表名就看得人头疼。但真等你要做数据迁移、做统计报表、或者要给第三方系统写接口时，这份文档就是你唯一的救命稻草。没有它，你连病历主表和医嘱明细表怎么关联都猜不出来，更别提去理解那些状态字段里存的到底是 0 还是 1，是 A 还是 B。这份联众电子病历表结构文档，本质上就是一套电子病历系统的数据库设计说明书，覆盖了从患者建档、门诊就诊、住院入出转，到病历文书、医嘱、检验检查结果、收费结算的完整链路。适合正在做 EMR 系统二次开发、数据平台对接、或者接手老旧医疗系统维护的工程师，拿到手能直接按图索骥，省掉逆向扒库的苦功夫。
2. 先读懂设计：核心业务表与主外键关系
2.1 从门诊到住院：六大业务主题域如何划分
电子病历系统的表结构，乍一看表很多，但按业务域切分后其实很清晰。整份文档里的表大体可以归为六大类：患者主数据、就诊流程数据、病历文书数据、医嘱与处方数据、检验检查数据、费用与结算数据。这六个域基本对应医院信息化的核心流程，你不管是要做统计报表还是做接口对接，八成都是在这些域的表之间打转。
患者主数据域的核心一般是一张患者基本信息表，通常叫 patient 或 pat_master_index，里面存放姓名、性别、出生日期、证件号、联系方式等静态信息。这张表的特点是每条记录对应一个自然人，但一个人可能来医院看多次病，所以它跟就诊表是一对多的关系。就诊流程数据域里，门诊有 visit 或 out_patient_visit 表，住院有 admission 或 in_patient_admission 表，记录的是某一次具体的就医行为，包括就诊时间、就诊科室、接诊医生、诊断等信息。这里有一个容易混淆的点：门诊就诊和住院登记虽然都叫"就诊"，但业务状态完全不同，文档里通常会用一张独立的 visit_type 或者用一个类型字段来区分，而不是共用一个标志。
病历文书数据域则是电子病历系统的重头戏，一般会有一张病历主表（medical_record）和一张病历明细表（medical_record_detail），主表记录病历的归属就诊、病历类型、书写医生、书写时间，明细表存具体的病历内容——可能是大字段文本，也可能是 XML 或结构化分段内容。医嘱与处方数据域的表通常包括医嘱主表（doctor_order）、医嘱明细表（order_item），以及处方相关的 prescription 表。检验检查域有 lab_test 和 exam_report 类表，费用域则有 billing 和 settlement 相关表。
以这份文档为例，它把各域之间的关联设计成了统一的 patient_id + visit_id 组合键模式。也就是说，几乎每一张业务表里都能找到这两个字段，patient_id 定位到人，visit_id 定位到某一次就诊，两者合起来就能把业务流转串起来。做查询时，基本就是靠这一对字段去 join 各业务域的表。
2.2 patient_id 贯穿全库的前世今生
如果你拿这份文档去逆向核对实际库，会发现 patient_id 这个字段几乎无处不在。这是这套电子病历表结构最核心的设计思路：不管业务表是门诊、住院、检验还是费用，都通过 patient_id 回溯到患者主索引。这样做的直接好处是：统计"某个患者在某段时间内做了几次检查、开了多少药、花了多少钱"这类跨域查询时，不需要层层 join 各业务域主表，只要在业务表上按 patient_id 分组就行。
但要注意，patient_id 并不总是唯一主键。比如门诊就诊表里，同一患者反复就诊会产生多条记录，所以就诊表通常用 patient_id + visit_id 做联合主键。再往下一层，医嘱表、检验表、费用表，每一层都往下挂自己的流水号，比如 order_id、lab_id、bill_id。我在实际项目里见过不少同事在写统计 SQL 时，直接按 patient_id join 两张业务表，结果统计结果翻了好几倍——原因是门诊表和住院表之间本身就有重叠，同一个患者在同一次住院期间可能既产生了住院医嘱，又产生了门诊费用记录。正确做法是先明确你统计的业务范围，再用 visit_id 约束到具体的就诊语境。
文档里对每个表的字段说明都标了主键和索引建议，这一点非常有用。实际做二次开发时，如果你要往这套结构里加自定义表，最好也遵循同样的键设计逻辑：首字段放 patient_id，业务流水号放第二字段，这样从数据架构层面就保持了统一性，别人接手时也容易看懂。
2.3 会诊记录表的双写姿势
多说一个容易被忽略的设计细节：会诊记录相关表。电子病历里的会诊记录，业务上既属于文书数据域，又涉及操作流程记录。文档中这张表——姑且叫 consultation_record——设计成了双写模式：一份数据写在文书表里用于展示和打印，另一份写在流程表里用于记录会诊申请、会诊科室、会诊医生、会诊状态这些动态信息。
这个双写设计对做接口对接的人来说特别重要。如果你只读了文书表，拿到的会诊记录永远是"最终版"，但医院业务上需要的是流程中每一步的操作记录，比如申请时间、指派给哪个科室、是否已回复。所以做会诊相关的接口时，建议以流程表的数据为准，文书表只做内容展示。反向来看，如果需要统计会诊量、会诊响应时长这类指标，也必须从流程表拉数据，而不是从文书表。
如果文档里没有明确标注这两张表的关系，使用时可以在字段注释或者外键定义里找找有没有 consultation_id 关联字段，一般都会留这个口子。
3. 落地与配置：手把手接入这套表结构
3.1 建库建表的三种姿势：哪种适合你
拿到文档后，第一步不是急着读字段，而是先把库结构建出来。文档里一般会附带完整的建库建表 SQL 脚本，或者你可以用文档里的字段说明手工生成。但不同数据库产品语法有差异，文档里默认的可能是 Oracle 或 SQL Server 写法，而你现在环境是 MySQL，这时候就得做语法适配。
常见做法有三种：一是直接用文档自带脚本原样执行，适合你本来就跑在 SQL Server 上、且版本接近的场景；二是手工抄表结构建表，适合没有脚本、只有字段说明的场景；三是用建模工具把文档里的 E-R 图关系转成建表语句，适合需要逆向维护数据字典的场景。
第一种要注意的问题是 SQL Server 与 MySQL 的字段类型映射。比如文档里如果写的是 varchar(max)，MySQL 里对应 longtext 或 json；文档里写 datetime2，MySQL 里直接用 datetime 就够；文档里如果有 uniqueidentifier（GUID），MySQL 里用 char(36) 存储更稳妥，性能和稳定性都比 binary(16) 更适合业务人员直查。这里有一张常用映射表，建议直接保存：
| SQL Server 类型 | MySQL 类型 | 说明 |
|---|---|---|
| int | int | 无差异 |
| bigint | bigint | 无差异 |
| varchar(n) | varchar(n) | 无差异 |
| varchar(max) | longtext | 病历大文本字段 |
| nvarchar(n) | varchar(n) | 注意字符集要统一 |
| datetime | datetime | 不要用 timestamp，范围太小 |
| datetime2(7) | datetime(6) | 精度降一档，微秒够用 |
| uniqueidentifier | char(36) | 存带横杠的 GUID 字符串 |
| bit | tinyint(1) | 0/1 布尔语义 |
如果你决定手工建表，还有一个细节：医嘱表、费用表这类高频访问的表，建议直接把索引设计也照抄过来，不要图省事只建主键。文档里通常会对索引有专门说明，标注了索引名和索引列，照着建就行。
3.2 初始化演示数据：先跑自带数据脚本再动手
文档一般会附带一个演示数据脚本，里面是几套模拟患者从挂号到出院的全流程数据。建议第一步就把这个脚本跑通，而不是先用空库去测接口。原因很简单：演示数据里面包含了完整的就诊链路，你可以拿它来验证自己写的 SQL 条件是否正确，排查问题时也能区分是数据问题还是代码问题。
以 SQL Server 为例，执行脚本的常见做法是打开 sqlcmd 或者 SSMS 的查询窗口，把脚本文件拖进去执行。如果脚本很大，建议分批次执行，一次跑完整库容易因为某个对象依赖顺序没对上而中断。下面是一段我在 SQL Server 里常用的验证脚本，用来确认演示数据是否完整加载：
-- 检查患者主数据是否已加载 SELECT COUNT(*) AS patient_cnt FROM patient; -- 检查就诊记录是否关联到患者 SELECT p.patient_id, v.visit_id, v.visit_date, v.dept_name FROM patient p LEFT JOIN out_patient_visit v ON p.patient_id = v.patient_id ORDER BY v.visit_date DESC; -- 检查病历文书与就诊记录关联 SELECT m.record_id, m.patient_id, m.visit_id, m.doc_type_name, m.doctor_name FROM medical_record m WHERE m.visit_id IS NOT NULL ORDER BY m.create_time DESC;这段脚本的逻辑依次是：先看患者总数，确认基本数据在；再看就诊记录能否关联到患者，确认主外键关系没有断；最后看病历文书是否能关联到就诊记录，确认病历数据链路是通的。执行完如果三个查询都有结果，说明演示数据基本可用，可以开始做业务接口测试。
如果没有现成的演示数据脚本，你也可以自己造。造数时要注意一点：就诊表的 visit_id 不要用自增数字，而要用带日期后缀的编码规则，比如"202506010001"，这样在排查时间跨度的统计问题时一眼就能看出数据分布。
3.3 存储过程与视图：文档里没写的常用封装
这套表结构在实际使用中，很多人会写一堆重复的联表查询。比如前端要展示某个患者的完整病历时间线，你得 join 入院记录、病程记录、出院记录、检验结果好几张表，每次写一遍太痛苦。我一般会建议把这类高频查询封装成视图或存储过程，既减少重复代码，也方便统一修改逻辑。
以"获取患者住院期间完整病历时间线"为例，可以用下面的方式做：
CREATE VIEW v_patient_record_timeline AS SELECT r.patient_id, r.visit_id, r.record_id, r.doc_type_name, r.create_time, r.doctor_name, '文书' AS record_source FROM medical_record r UNION ALL SELECT l.patient_id, l.visit_id, l.lab_no AS record_id, '检验报告' AS doc_type_name, l.report_time AS create_time, l.reviewer AS doctor_name, '检验' AS record_source FROM lab_report l UNION ALL SELECT e.patient_id, e.visit_id, e.exam_id AS record_id, '检查报告' AS doc_type_name, e.report_time AS create_time, e.doctor_name, '检查' AS record_source FROM exam_report e;这个视图把病历文书、检验报告、检查报告三类记录合并成一个时间线数据集，调用方只需要按 patient_id 和 visit_id 过滤，再按 create_time 排序，就能得到完整的就诊时间线。视图里每段 UNION ALL 的字段顺序必须完全一致，包括字段个数和数据类型，否则创建会失败。这里用 UNION ALL 而不是 UNION 是因为同一时间点可能既有检验报告又有病历文书，UNION 去重会丢数据。
参数上面要注意：如果业务上只需要最近半年的数据，建议在视图里加一个时间过滤条件，避免每次查询都扫描全表。比如 create_time >= DATEADD(month, -6, GETDATE())，这个条件在 SQL Server 里可以直接写进视图定义，MySQL 则用 DATE_SUB(NOW(), INTERVAL 6 MONTH)。
4. 从文档到实战：四个可直接复用的统计查询
4.1 按科室分组的就诊人次统计
做医院管理报表的人，最常被问到的一个问题是"上个月各科室的门诊量是多少"。这个统计在文档结构里实现起来非常直接：out_patient_visit 表里记录了每次就诊的科室和就诊时间，按科室分组计数即可。
SELECT dept_name, COUNT(*) AS visit_cnt, COUNT(DISTINCT patient_id) AS unique_patient_cnt FROM out_patient_visit WHERE visit_date >= '2025-06-01' AND visit_date < '2025-07-01' GROUP BY dept_name ORDER BY visit_cnt DESC;这里有两个指标要注意区分：visit_cnt 是就诊人次，同一个患者来两次就算两次；unique_patient_cnt 是去重后的患者人数，用 COUNT(DISTINCT patient_id) 得到。临床上这两个指标都有意义，门诊量一般看人次，慢病管理看人数。如果你统计时只写了 COUNT(*)，出来的数字就是人次，别把它当患者数汇报给业务方。另外，visit_date 字段的过滤条件用左闭右开区间可以避免边界问题。
4.2 病历书写及时性检查：时限投诉与缺项
电子病历质控里有一项硬指标：入院记录必须在患者入院后 24 小时内完成。这类检查用表结构里的 create_time 与 admission_time 做差值就能算出来。
SELECT a.patient_id, a.visit_id, a.admission_time, MIN(r.create_time) AS first_record_time, DATEDIFF(hour, a.admission_time, MIN(r.create_time)) AS hours_diff, CASE WHEN DATEDIFF(hour, a.admission_time, MIN(r.create_time)) > 24 THEN '超时' ELSE '及时' END AS status FROM in_patient_admission a INNER JOIN medical_record r ON a.patient_id = r.patient_id AND a.visit_id = r.visit_id WHERE r.doc_type_code = 'admission_note' GROUP BY a.patient_id, a.visit_id, a.admission_time ORDER BY hours_diff DESC;执行这个查询要注意两个坑：一是入院记录可能有多次修改，MIN(r.create_time) 取的是首次创建时间，而不是最终提交时间，如果要统计"完成时间"应该取第一次提交状态变更的时间，那就需要关联状态流转表；二是 DATEDIFF 的粒度，SQL Server 里 hour 粒度是整数，不足一小时会被截断，如果一个记录是在第 24 小时 59 分创建的，算出来的 hours_diff 是 24 而不是 25，会被误判为及时。这种场景建议用分钟粒度再除以 60，或者直接比较时间点，如下：
-- 更精确的时限判断：直接比较时间点 SELECT a.patient_id, a.visit_id, CASE WHEN MIN(r.create_time) > DATEADD(hour, 24, a.admission_time) THEN '超时' ELSE '及时' END AS status FROM in_patient_admission a INNER JOIN medical_record r ON a.patient_id = r.patient_id AND a.visit_id = r.visit_id WHERE r.doc_type_code = 'admission_note' GROUP BY a.patient_id, a.visit_id, a.admission_time;这个写法用 DATEADD 在入院时间上加 24 小时得到一个截止时间点，再直接跟首次记录时间比较，不涉及取整误差，判断结果更可靠。
4.3 跨表拼接：把医嘱与检验结果串联
医嘱和检验结果在业务上是两条独立的链路，但做临床路径分析时经常要放在一起看：某个患者在某天开了什么药，当天检验结果是什么。其实两者之间没有直接外键关系，只能通过 patient_id + visit_id + 时间窗口做模糊关联。
SELECT o.patient_id, o.visit_id, o.order_date, o.order_text AS med_name, o.dosage, o.frequency, o.doctor_name AS order_doctor, l.lab_item_name, l.lab_result, l.reference_range, l.lab_time FROM doctor_order o LEFT JOIN lab_report_result l ON o.patient_id = l.patient_id AND o.visit_id = l.visit_id AND ABS(DATEDIFF(hour, o.order_time, l.lab_time)) <= 24 WHERE o.order_type = 'medication' AND o.patient_id = 'P00001024' ORDER BY o.order_date, l.lab_time;这里用了时间窗口关联，即医嘱开始时间和检验报告时间相差在 24 小时之内就算同一次诊疗事件。这种做法在业务上说得通，但要注意 ABS(DATEDIFF(...)) <= 24 这种写法会放弃索引，数据量大时性能较差。如果只是查单个患者，问题不大；如果要跑全量数据，建议先把两个数据集按患者和就诊分别取出，在应用层做内存关联。另外，LEFT JOIN 意味着有的医嘱没有检验结果，输出时 medical_result 字段会是 NULL，前端展示要做空值处理。
4.4 费用与就诊的联动统计
费用表在整个文档里是比较容易踩坑的一块，因为费用往往拆成了主表和明细表，主表记录一笔费用的总金额和结算状态，明细表记录具体收费项目。统计某科室某月的收入，需要从明细表入手，按收费项目所属科室聚合。
SELECT bd.dept_name, DATE_FORMAT(b.create_time, '%Y-%m') AS charge_month, SUM(bd.amount) AS total_amount, COUNT(DISTINCT b.patient_id) AS billing_patient_cnt FROM billing_detail bd INNER JOIN billing b ON bd.bill_id = b.bill_id WHERE b.pay_status IN ('paid', 'partial') AND b.create_time >= '2025-06-01' AND b.create_time < '2025-07-01' GROUP BY bd.dept_name, DATE_FORMAT(b.create_time, '%Y-%m') ORDER BY total_amount DESC;注意 pay_status 字段的取值是文档里定义好的字典值，不同版本可能不一样，有的是 'paid' / 'unpaid'，有的直接是 0 / 1 / 2。写查询之前先去数据字典表里确认一下，别想当然。COUNT(DISTINCT b.patient_id) 统计的是付过费的患者数，如果业务方要的是"账单数"，直接用 COUNT(*) 就行。
5. 避坑与调试：整理这套表结构时的五个常见问题
5.1 没有主键的业务表如何定位单行
现象：有部分明细表没有主键字段，比如医嘱明细表里的行项目、病历分段表里的段落记录，查询结果里会出现完全重复的行，做 UPDATE 或 DELETE 时没法精确定位到某一条。
原因：这类表在原始设计里属于"流水明细"，业务上只做追加不做修改，所以设计者没有设置主键。但实际使用中，我们需要修正录错的药物剂量或删除误写的病程段落。
解决：不要自己去加自增主键，很可能导致应用层插入语句报错。更稳妥的办法是用联合条件定位行：patient_id + visit_id + 行号字段 + 创建时间。如果实在没有行号，可以用 ROW_NUMBER() 窗口函数生成临时的行号来做定位：
;WITH numbered AS ( SELECT *, ROW_NUMBER() OVER (PARTITION BY patient_id, visit_id ORDER BY create_time) AS rn FROM order_items ) DELETE FROM order_items WHERE patient_id = 'P00001024' AND visit_id = 'V20250601001' AND EXISTS ( SELECT 1 FROM numbered n WHERE n.patient_id = order_items.patient_id AND n.visit_id = order_items.visit_id AND n.create_time = order_items.create_time AND n.rn = 3 );这个方法本质上是借助窗口函数模拟出一个业务主键，只在找不到其他定位依据时使用。执行前一定要先 SELECT 确认 rn 对应的行是你想删的那一条，血的教训是 rn 按时间排序后第 3 条不一定是最早的第 3 条，而可能是重复值的任意一条。
5.2 时间字段究竟是 datetime 还是 char(8)
现象：从文档里看到记录时间的字段注释写的是"记录时间"，值却是 2025-06-01，而另一张表里的同类字段存的是 2025-06-01 14:30:22，导致做时间比较时，一边是字符串一边是时间类型，报错或者匹配不到。
原因：这套表结构经过多年迭代，早期建的表用 char(8) 存日期，后补的表用 datetime 存完整时间，两代表并存，文档没有明确标注字段类型差异。
解决：统一用 CONVERT 或 CAST 把字符串日期转成 datetime 再比较，不要依赖隐式转换。SQL Server 里这样处理：
-- 把 char(8) 的日期字段统一转为 datetime SELECT * FROM visit_record WHERE CONVERT(datetime, visit_date, 120) >= '2025-06-01';参数 120 表示 ODBC 规范格式，对应 yyyy-mm-dd hh:mi:ss。如果你的字符串实际格式是 yyyymmdd，直接用 120 会解析失败，要改用 112。拿到这类旧表时，第一件事不是写业务查询，而是先探查一下所有时间字段的实际存储格式，用 INFORMATION_SCHEMA.COLUMNS 查一遍，避免后面整个项目里都带着这个隐患。
5.3 状态字段值是代码还是中文
现象：费用表里有个状态字段叫 charge_status，文档说明里写着"收费状态"，没有给出字典表，结果有的库里面存的是 '1'、'2'，有的是 'PAID'、'UNPAID'，还有的直接存了中文'已收费'。
原因：这套系统经历了不同版本迭代，开发人员在不同时期用了不同的代码规范，又没有强制走数据字典，导致脏数据混入。
解决：写代码时把状态判断封装成一个独立函数或配置表，不要在业务 SQL 里到处硬编码。比如：
-- 先查现状：这个字段到底有几种值 SELECT charge_status, COUNT(*) AS cnt FROM billing GROUP BY charge_status;执行完这个 SQL 后，把返回的每种值都标记出来，再写一个干净的映射关系，统一转换成你新系统里的标准枚举。我在实际项目里处理过一张 60 万行的费用表，跑完 GROUP BY 发现状态值有 7 种，其中 '1'、'01'、'已收费' 居然表示同一个含义。这种问题不提前排查，后面每个统计报表都会出错。
5.4 触发器导致批量更新超时
现象：往医嘱明细表批量插入 5000 条数据时，事务执行超时，其他业务操作也变慢，数据库 CPU 飙高。
原因：这套表结构里自带触发器，在医嘱明细表插入时联动更新医嘱主表的最后操作时间字段，正常情况下没有问题，但在批量导入场景下，每插入一条就触发一次 UPDATE，5 万条数据就是 5 万次额外写操作，性能直接崩掉。
解决：批量导入前和数据库管理员确认能否暂时禁用触发器，或者改用分批提交的方式。分批提交更安全，下面是常见做法：
DECLARE @batch_size INT = 1000; DECLARE @offset INT = 0; WHILE @offset < (SELECT COUNT(*) FROM staging_order_items) BEGIN INSERT INTO order_items (patient_id, visit_id, order_id, item_code, dosage, create_time) SELECT patient_id, visit_id, order_id, item_code, dosage, create_time FROM staging_order_items ORDER BY item_id OFFSET @offset ROWS FETCH NEXT @batch_size ROWS ONLY; SET @offset = @offset + @batch_size; WAITFOR DELAY '00:00:00:100'; END;这里每次只提交 1000 条，每条事务的锁持时间短，对主表触发器的压力也被分摊到多次较小的事务中。WAITFOR DELAY 是给数据库一点喘息时间，避免连续大事务触发锁升级。如果批量导入工具支持批次大小参数，优先用工具配置而不是自己写循环。
5.5 文档版本与库结构对不上时怎么办
现象：文档里写的表名是 out_patient_visit，但实际数据库里这张表叫 clinic_visit，字段也少了两个。用文档里的 SQL 去查询直接报错"对象名无效"。
原因：这套文档是某项目交付时导出的版本，但库结构在项目上线后又经历了几次小版本升级，字段表名都有过调整，文档没有同步更新。
解决：先把文档里的表名在库里探一遍，确认实际表名和字段。可以查系统表，不用翻数据字典：
-- SQL Server 下查看某类表是否存在 SELECT name FROM sys.tables WHERE name LIKE '%visit%'; -- MySQL 下查看字段差异 SELECT COLUMN_NAME, DATA_TYPE FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'out_patient_visit';如果发现表不存在，就用模糊匹配找相近的表名。找到实际表后，把文档里的关键字段和实际字段做一次映射，维护一张对照表放进工程文档里。做这一步能省下后面无数次的查询报错排查。文档只是参考，库里的真实结构才是唯一真相。
6. 最后一步：用数据字典反向验证表结构
6.1 核对三件套：库、表、字段三个维度的验证
拿到这份文档后，不要急着直接拿来做开发，先用你手上的库和文档做一次全面的数据字典核对。我习惯的做法是三条 SQL 快速跑完，能覆盖大部分结构偏差。
-- 1. 找出文档里存在但库里没有的表 SELECT t.name AS missing_table FROM ( VALUES ('patient'), ('out_patient_visit'), ('in_patient_admission'), ('medical_record'), ('doctor_order'), ('lab_report') ) AS doc_tables(name) LEFT JOIN sys.tables t ON t.name = doc_tables.name WHERE t.name IS NULL; -- 2. 找出核心表的字段数量差异 SELECT c.TABLE_NAME, COUNT(*) AS actual_col_cnt FROM INFORMATION_SCHEMA.COLUMNS c WHERE c.TABLE_NAME IN ('patient', 'medical_record') GROUP BY c.TABLE_NAME;表名核对完，字段名核对也有一个技巧：把文档里描述的字段清单和实际库里的字段清单导出，做一次文本 diff。如果 DIFF 结果超过 20 行，建议直接把文档版本标记为过时，按照实际库结构重新整理一份数据字典。如果差异小，以实际库为准修正文档就好。
6.2 迁移前必做的兼容性检查
如果你要从旧系统往新系统迁移，或者要把这套数据接入大数据平台，做兼容性检查是必须的。重点检查三件事：字符集是否一致，时间字段是否全为 datetime 类型，以及所有过期数据是否标记了有效状态。
-- 检查时间字段是否有非 datetime 类型 SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE FROM INFORMATION_SCHEMA.COLUMNS WHERE DATA_TYPE IN ('varchar', 'char', 'nvarchar') AND COLUMN_NAME LIKE '%time%' OR COLUMN_NAME LIKE '%date%';这个查询找出来的是那些名字看着像时间字段但类型是字符串的列，通常就是旧版设计里用 char(8) 存日期或者用了 varchar(20) 存约诊时段的地方。这类字段在迁移时一定要用 CASE WHEN 逐一转换，直接批量 CAST 很容易报错。还有一条经验：迁移测试时，用 demo 数据全流程跑通后再做全量迁移，不要拿生产数据直接试，那样出了问题连后悔药都没得吃。
从那以后，我每次拿到这类表结构文档的第一天，什么都不做，先把文档里的表名、字段、类型和真实库里的结构做一次完整 diff，输出一份差异清单再动手写代码。整个过程大概半天，但能避免后续一个月的返工。很多所谓"查不出来"的历史数据问题，根源都在于表和文档对不上。希望这份踩坑清单能帮你省下同样的时间，少掉几个不该掉的头发。
本文还有配套的精品资源，点击获取
