88 lines
3.5 KiB
Markdown
88 lines
3.5 KiB
Markdown
# 本地库 vs 线上库 结构差异分析报告
|
||
|
||
| 项目 | 信息 |
|
||
| --- | --- |
|
||
| 本地库 | `192.168.20.100:33080` / `safety-eval-service` |
|
||
| 线上库 | `nlb-kd2xz70qhllfet2koj.cn-beijing.nlb.aliyuncsslb.com:33068` / `safety-eval-service` |
|
||
| 分析时间 | 2026-08-11 |
|
||
| 执行动作 | 仅 `SELECT information_schema` 只读查询，**未对线上做任何变更** |
|
||
|
||
## 一、总体结论
|
||
|
||
| 检查项 | 结果 |
|
||
| --- | --- |
|
||
| 本地表数 / 线上表数 | 60 / 60 |
|
||
| 线上缺表 | **0** |
|
||
| 线上多表 | 0 |
|
||
| 线上缺字段 | **8**（全部集中在 `org_info`） |
|
||
| 线上多字段 | 0 |
|
||
| 字段定义不一致 | **3** |
|
||
| 线上缺索引 | 0 |
|
||
|
||
整体差异很小，核心问题是 `org_info` 表缺少一批「原型 V1.6」新增字段。
|
||
|
||
## 二、线上缺失字段（`org_info`，8 个）
|
||
|
||
均为可空、无默认值，补齐对存量数据无影响。
|
||
|
||
| 字段 | 类型 | 可空 | 说明 |
|
||
| --- | --- | --- | --- |
|
||
| `qualification_cert_no` | varchar(100) | 是 | 资质证书编号 |
|
||
| `fax` | varchar(20) | 是 | 传真 |
|
||
| `contact_name` | varchar(50) | 是 | 联系人（由 `contact_name_phone` 拆分） |
|
||
| `contact_phone` | varchar(20) | 是 | 联系电话（由 `contact_name_phone` 拆分） |
|
||
| `contact_name_phone` | varchar(100) | 是 | 联系人及电话 |
|
||
| `fixed_assets_total` | decimal(16,4) | 是 | 固定资产总值（万元） |
|
||
| `apply_business_scope` | varchar(500) | 是 | 拟申请的法定安全评价业务范围 |
|
||
| `org_intro` | text | 是 | 单位基本情况介绍 |
|
||
|
||
> 注：本地同时存在拆分后的 `contact_name` / `contact_phone` 与合并的 `contact_name_phone`，属于过渡期并存。是否三者全部上线，建议结合业务代码确认后再定。
|
||
|
||
## 三、字段定义不一致（3 处）
|
||
|
||
### 1. `eval_process_control.reviewer_signature_task_status` — 可安全对齐
|
||
|
||
仅注释文案不同，类型 `varchar(64)`、`NOT NULL`、默认值 `non_dispatched` 均一致。
|
||
|
||
- 线上：`审核签字任务状态 ...`
|
||
- 本地：`过程控制审核签字任务状态 ...`
|
||
|
||
### 2 & 3. `org_info` 两个行业类别字段 — 存在数据截断风险，不建议改线上
|
||
|
||
| 字段 | 线上 | 本地 |
|
||
| --- | --- | --- |
|
||
| `safety_industry_category_code` | varchar(512) | varchar(32) |
|
||
| `safety_industry_category_name` | varchar(1024) | varchar(50) |
|
||
|
||
**线上字段比本地更宽**，而非缺失或落后。实测线上存量数据：
|
||
|
||
| 字段 | 最大长度 | 超出本地长度的行数 |
|
||
| --- | --- | --- |
|
||
| `safety_industry_category_code` | 110 | 2 行 > 32 |
|
||
| `safety_industry_category_name` | 57 | 1 行 > 50 |
|
||
|
||
本地对应数据最大长度仅 25 / 14，说明本地只是从未触发过加宽需求。
|
||
|
||
**结论：若按本地定义收窄线上，会直接截断线上真实数据，造成不可逆丢失。**
|
||
正确做法是反向对齐——把本地改宽到与线上一致，相关语句已在 SQL 文件第五节给出。
|
||
|
||
## 四、索引
|
||
|
||
线上不存在缺失索引，无需处理。
|
||
|
||
## 五、交付物
|
||
|
||
| 文件 | 用途 |
|
||
| --- | --- |
|
||
| `online_schema_upgrade.sql` | 升级 SQL（含备份、执行、校验，风险项已注释隔离） |
|
||
| `schema_diff.json` | 结构化差异明细 |
|
||
| `compare_schema.py` | 只读对比脚本，可重复执行复核 |
|
||
|
||
## 六、执行建议
|
||
|
||
1. 先备份 `org_info`（SQL 第一节）。
|
||
2. 执行第二节补字段、第三节对齐注释——这两项无数据风险。
|
||
3. 第四节保持注释状态，**不要在线上执行**。
|
||
4. 第五节在本地库执行，消除最后的长度差异。
|
||
5. 用第六节语句校验结果。
|