前言

阶段五把接诊工作台的排版、日历和字号收了一遍。联调时若本机仍用早期的 ry-fastapi_demo.sql 建库，而代码已按 module_clinic 的 ORM 加了 med_bed.floor、med_prescription.prescription_no 等字段，很容易出现 MySQL 1054 Unknown column——接口 500，堆栈指向 SQLAlchemy 生成的 SELECT，容易误判成业务 bug。

本篇不改业务逻辑，只讲 三份 SQL 源如何跑偏、如何用 diff + 增量脚本把运行库对齐 ORM，并给新同学一条可重复的 checklist。下文按问题—根因—改法—踩坑的流程写，便于 CSDN 发文和同组交接。

---

目录（仅供提示）

1. 背景与阶段六目标
2. 现象：1054 从哪条链路冒出来
3. 根因：struct、demo、运行库三源不一致
4. 对比：diff_sql_tables.py 怎么用
5. 修复：upgrade_align_module_clinic_orm.sql
6. 验收与长期维护
7. 踩坑与团队规范
8. 结语与下阶段排期

---

正文

1. 背景与阶段六目标

业务上：医生打开接诊工作台、在院患者、处方列表时，后端要 JOIN 床位、查处方主表/明细。库少一列，整页白屏或 500，和「功能没做完」在演示上很难区分。

工程上：

• ORM 为准：module_clinic/entity/do/ 里 MedBed、MedPrescription 等已声明新列。
• SQL 文件有两套：sql/patient/patient_struct.sql（偏完整结构）、sql/医生端sql/ry-fastapi_demo.sql（课堂/演示常用，往往滞后）。
• 运行库是第三份：同事 A 用 demo 导库、你 B 只 git pull 不跑 SQL，就会出现「代码新、库旧」。

阶段六交付：

项	验收
能读懂 1054 堆栈里的表名、列名	对照 ORM / struct 确认缺什么
能跑 diff 列出 struct 与 demo 差集	python scripts/diff_sql_tables.py
能对已有库增量补列	执行 upgrade_align_module_clinic_orm.sql 可重复、不报错
同一接口复测无 1054	如工作台 bootstrap、处方列表

---

2. 现象：1054 从哪条链路冒出来

典型报错（控制台或日志）：

pymysql.err.OperationalError: (1054, "Unknown column 'med_bed.floor' in 'field list'")

或：

Unknown column 'med_prescription.prescription_no' in 'field list'

常见触发页面（任一条即可复现）：

• 接诊工作台 → 加载「我的在院患者」（JOIN med_bed，ORM 带 floor）
• 处方管理 → 列表/详情（prescription_no、pay_status 等）

注意：这是 schema 问题，不是 Vue 传参错、也不是权限 403。改前端无效，必须动库或换对齐后的 SQL 建库。

---

3. 根因：struct、demo、运行库三源不一致

可以把项目里和表结构相关的来源看成三条线：

patient_struct.sql → 目标结构（与 ORM 演进同步的方向）

ry-fastapi_demo.sql → 演示/旧环境导库脚本（常落后）

本机 MySQL 实际表结构 → 以上谁建库、是否跑过 upgrade 决定

问题链（博文主线）：

开发在 ORM 上新增 Column

→ 本机/队友仍用旧 demo.sql 建库或未执行增量脚本

→ SQLAlchemy 生成 SELECT 包含 floor / prescription_no / …

→ MySQL 1054 Unknown column

和实训五的关系：实训五改日历、排版时若库未对齐，会先看到 500，容易误以为是 day 参数写坏——本篇用来把环境问题单独说清楚。

---

4. 对比：diff_sql_tables.py 怎么用

作用：只对比两个 SQL 文件里 CREATE TABLE 的列名集合，不连数据库。快速回答「demo 相对 struct 缺了哪些列、哪些表只在 struct 里有」。

路径（相对 ruoyi-fastapi-backend）：

• sql/patient/patient_struct.sql
• sql/医生端sql/ry-fastapi_demo.sql
• 脚本：scripts/diff_sql_tables.py

执行：

cd ruoyi-fastapi-backend

python scripts/diff_sql_tables.py

输出含义：

• patient_struct 有、demo 缺: [...] → demo 文件里 CREATE 少列，新同学用 demo 建库会缺这些列
• 列名集合一致 → 两个文件在该表上已对齐（不代表你本机库一定对齐，本机可能更早是旧 demo 建的）
• 仅在 patient_struct → demo 文件里没有整张表，需另备迁移或不用该功能

我这边一次跑出来的要点：

• med_bed、med_inpatient_registration 等多数同名表已显示 列名一致（说明 demo 的 CREATE 已改过一轮）。
• med_prescription demo 仍缺：dispense_by、dispense_status、dispense_time、pay_status、prescription_type、refund_status、total_amount 等（prescription_no 若 demo 已补则不会出现在缺省列表里）。
• med_prescription_item demo 缺：material_id、material_code、unit_price、line_amount、item_status 等。
• 仅在 struct 的表：med_charge_bill、med_followup_plan 等——本篇增量脚本不建表，用不到可暂不处理。

实现效果如下：

局限（写进博文避免误导）：

• 只比 列名，不比类型、默认值、索引。
• 不比 运行库；本机已 1054 时，还要 SHOW COLUMNS FROM med_bed 或跑 upgrade。

---

5. 修复：upgrade_align_module_clinic_orm.sql

定位：对已有数据的库做 ADD COLUMN，列已存在则跳过，可重复执行。

文件：sql/patient/upgrade_align_module_clinic_orm.sql

核心机制：

1. 临时存储过程 sp_add_column_if_missing。
2. 查 information_schema.COLUMNS，当前库、当前表、列名不存在才 ALTER TABLE ... ADD COLUMN。
3. 脚本末尾 DROP PROCEDURE，不留垃圾对象。

当前覆盖范围（与 ORM 强相关、1054 高发）：

表	补列示例
med_bed	floor, room_no, dept_name, bed_type
med_inpatient_registration	dept_name, doctor_name, bed_no
med_prescription	prescription_no, prescription_type, pay_status, dispense_*, refund_status, total_amount 等
med_prescription_item	material_id, material_code, unit_price, line_amount, item_status

执行示例（库名、账号按 .env.dev 修改）：

mysql -h127.0.0.1 -uroot -p我的密码 ry-vue-fastapi < sql/patient/upgrade_align_module_clinic_orm.sql

或在 Navicat / DBeaver 打开该文件对目标库执行。

设计取舍：

• 只 ADD，不 MODIFY：若库里已有 total_amount 且类型是 decimal，脚本不会自动改成 ORM 的 BIGINT，需单独评估迁移；缺列时新增默认为 bigint。
• 索引在文件末尾注释：idx_med_rx_dispense 等需手工执行，重复建索引会报错，不要无脑粘贴。

改法摘要：

1. 用 diff 知道 demo 文件差在哪。
2. 用 upgrade 把 运行库补到能跑 ORM。
3. 有空再把 ry-fastapi_demo.sql 里对应 CREATE TABLE 与 struct 对齐，减少下一位队友踩坑（med_bed 我们已对齐过一版，处方相关建议继续补）。

---

6. 验收与长期维护

步骤 4：验收

1. 重启后端：python app.py --env=dev。
2. 医生账号 → 接诊工作台 → 在院患者、候诊应正常返回 JSON。
3. 处方列表/详情再点一遍。
4. 可选：再跑 diff_sql_tables.py，确认 demo 文件层面仍有哪些表待合并；运行库用 information_schema 抽查即可。

长期维护建议：

动作	何时
pull 代码后跑 upgrade	ORM 有新增 Column 的合并
改 demo 的 CREATE	发版/交作业前，与 struct 对齐
新表只在 struct	写独立建表 SQL 或说明「演示环境不启用」

---

7. 踩坑与团队规范

踩坑	说明
只 pull 不跑 SQL	最常见；表现就是 1054
把 1054 当业务 bug 改 Vue/Python 逻辑	浪费时间
对已有列重复执行 upgrade	一般安全（过程会跳过）；重复 CREATE INDEX 会失败
diff 显示一致但本机仍 1054	本机库是更早旧 demo 建的，必须对运行库执行 upgrade
total_amount 类型不一致	列已存在且为 decimal 时，upgrade 不会改类型，金额异常要单独查
造旧库对比写博	可用旧 demo 备份库执行 upgrade 前后截图，不必故意弄挂生产

新同学 checklist（可贴在组内 Wiki）：

1. 克隆仓库，配置 .env.dev 数据库名。
2. 导入 demo 或已有库 → 执行 upgrade_align_module_clinic_orm.sql。
3. python scripts/diff_sql_tables.py 看一眼 demo 是否仍缺列。
4. 启后端 + 前端，进工作台 smoke test。

---

8. 结语与下阶段准备

阶段六把 ORM 与 MySQL 不一致 从联调事故里拆出来：先读 1054 里的表/列，再用 diff 对文件、用 upgrade 对运行库，最后把 demo SQL 跟上，避免代码更新、数据库未更新。

本篇刻意未展开：整表缺失（仅 struct 有的随访/收费表）、字段 类型 迁移、生产环境回滚策略——需要时可单独写一篇迁移与回滚。

下阶段可设计：实训六 UI 向——候诊 Tab（待接诊/已完成）；或 P3 智能辅助异步回写；或三端排班方案篇。