6.5 KiB
6.5 KiB
高风险数据库迁移清单与执行顺序
适用范围:
leaudit-platform当前从area/region过渡到tenant_code的高风险数据库收口阶段
更新日期:2026-05-21
文档定位:明确高风险阶段数据库需要补哪些字段、为什么补、执行顺序是什么、哪些脚本需要先后落地。
1. 目标
本清单只解决一个核心问题:
当前多个核心业务表仍没有把 tenant_code 作为真实归属主字段,导致代码层即使传了 tenant_code,最终也只是转成中文 area/region 去查。
高风险数据库阶段的目标是:
- 所有核心业务主表具备真实
tenant_code - 查询和写入具备切到
tenant_code主链的基础 - 历史
area/region/default/省级/公共有明确回填路径
2. 高风险表清单
2.1 必须补字段的主表
D1 leaudit_documents
当前现状:
- 模型层只有
region - 文档、公文、交叉评查、版本链大量依赖该表
必须新增:
tenant_code VARCHAR(64) NULL
建议索引:
idx_leaudit_documents_tenant_codeidx_leaudit_documents_type_tenant_name_latest说明:替代当前依赖region的版本匹配索引
D2 contract_templates
当前现状:
- 主表只有
region - service 返回里仍存在
'' AS tenant_code
必须新增:
tenant_code VARCHAR(64) NULL
建议索引:
idx_contract_templates_tenant_code_activeuq_contract_templates_tenant_code_code_active
D3 usage_login_events
当前现状:
- 只有
area_snapshot - 登录统计无法稳定按租户回溯
必须新增:
tenant_code_snapshot VARCHAR(64) NULLtenant_name_snapshot VARCHAR(128) NULL
建议索引:
idx_usage_login_events_tenant_code
D4 rag_dataset
当前现状:
- 只有
area - 数据集可见性和编辑权限仍依赖旧地区模型
必须新增:
tenant_code VARCHAR(64) NULL
建议索引:
idx_rag_dataset_tenant_code- 后续可替代
idx_rag_dataset_area
D5 rag_chat_app
当前现状:
- 只有
area - 聊天应用可见性仍跟旧地区字段耦合
必须新增:
tenant_code VARCHAR(64) NULL
建议索引:
idx_rag_chat_app_tenant_code
D8 evaluation_points
当前现状:
- 真实运行链路仍使用旧表
evaluation_points - 评查点模块代码已切到
tenant_code优先,但旧表仍可能只有area - 若数据库不补列,模块只能长期停留在兼容态
必须新增:
tenant_code VARCHAR(64) NULLtenant_name VARCHAR(128) NULL
建议索引:
idx_evaluation_points_tenant_codeidx_evaluation_points_group_tenant_codeidx_evaluation_points_group_pid_tenant_code
2.2 暂不直接补字段,但依赖主表收口的表
D6 govdoc_runs / govdoc_rule_results / govdoc_report_artifacts
结论:
- 暂不优先单独加
tenant_code - 先通过
govdoc_runs.document_id -> leaudit_documents.tenant_code间接收口 - 等主链稳定后,再评估是否补冗余快照列提升报表与筛选性能
D7 leaudit_audit_runs / 评查结果衍生表
结论:
- 暂不优先单独加
tenant_code - 先通过
document_id -> leaudit_documents.tenant_code收口 - 若后续统计或明细页性能不足,再追加快照字段
3. 历史数据回填规则
3.1 统一回填原则
所有历史回填统一按下面顺序处理:
- 若已有
tenant_code且合法,保留 - 否则根据原
tenant_code对应编码直接回填 - 否则根据
tenant_name - 否则根据
area - 否则根据
region - 若值为
default / 公共 / 省级 / 空值,回填为规范编码
规范编码建议:
PUBLICPROVINCIAL
3.2 别名映射来源
优先使用:
sys_tenantssys_tenant_aliases
不再允许长期使用硬编码映射表作为正式来源。
3.3 风险点
以下数据回填前必须预检:
- 同一个中文地区名是否映射到多个租户编码
- 是否存在脏数据:空格、大小写、历史缩写混用
- 是否存在已经改名但旧数据仍用旧租户名的记录
4. 执行顺序
4.1 第一步:补列,不切读写
执行内容:
- 给
leaudit_documents contract_templatesusage_login_eventsrag_datasetrag_chat_appevaluation_points
先补 tenant_code 或快照字段及索引。
目标:
- 不影响当前存量逻辑
- 为后续渐进式代码改造做准备
4.2 第二步:做历史回填
执行内容:
- 用
sys_tenant_aliases回填历史region/area - 对
PUBLIC/PROVINCIAL做统一归并
目标:
- 让存量数据先具备基础
tenant_code - 避免代码一切换就出现大量空值
4.3 第三步:后端改读写
执行内容:
- 文档模块先切
- 公文模块第二个切
- 合同模板第三个切
- 统计与 RAG 随后切
目标:
- 读写统一以
tenant_code为主 region/area退化为兼容展示字段
4.4 第四步:补约束与清理旧索引
等代码和数据稳定后再做:
- 评估
tenant_code是否可加NOT NULL - 评估是否可将唯一索引从
region改为tenant_code - 逐步淘汰旧
area/region主过滤索引
5. 本轮建议新增的 SQL 脚本
建议新增一个统一高风险迁移脚本:
scripts/创建sql/schema_tenant_code_high_risk_phase1.sqlscripts/创建sql/schema_evaluation_points_tenant_cleanup.sql
建议内容:
- 给核心业务表补
tenant_code/tenant_code_snapshot - 建立基础索引
- 执行首轮历史回填
- 对评查点旧表单独补
tenant_code/tenant_name与共享域标准编码回填
后续再拆第二阶段脚本:
scripts/创建sql/migrate_tenant_code_high_risk_phase2_cleanup.sql
用于:
- 强化约束
- 调整唯一索引
- 清理旧索引
6. 验收标准
数据库层本阶段完成后,应满足:
- 核心业务主表都能查到
tenant_code - 核心历史数据回填完成率可统计
PUBLIC / PROVINCIAL已规范化- 后端可以在不依赖中文
area/region的前提下完成后续主链改造
7. 本轮直接执行项
本轮直接开始:
- 新增
schema_tenant_code_high_risk_phase1.sql - 先补列与索引
- 加入首轮基于
sys_tenant_aliases的历史回填 SQL - 评查点模块单独补充 schema_evaluation_points_tenant_cleanup.sql,用于旧表
evaluation_points的收尾
随后再进入 service 层改造。