现状分析
目前，在现有多租户系统中，存在着以下问题：
- mp_plan_info计划表单表存储量大，个例大数据量租户，已经存储了千万级别的数据量；
- 由于mp_plan_info计划表数据量大，导致涉及到该表的数据库查涧、插入、更新、删除等操作性能低下，慢SQL等问题层出不穷，影响系统性能且浪费服务器资源；
- 由于mp_plan_info计划表数据量大，导致系统页面加载缓慢，影响用户体验；
- mp_plan_info计划表有效数据跟历史无效数据混杂在一起，实际用到的数据只是占一小部分，每一次工单动态调整或者电梯修改维保计划，都会大批量产生无效的历史维保计划记录，导致mp_plan_info计划表膨胀过快；
优化方案
鉴于以上分析，我们提出以下优化方案：
表存储结构优化
-
新增一张mp_plan_info_his计划历史表，表结构与mp_plan_info计划表保持一致，原来的mp_plan_info只存储电梯当前有效的维保计划，mp_plan_info_his只存储电梯最新的历史维保计划，借以排查生产用户反馈的问题；
-
由于mp_plan_info是千万级别的大表，而我们需要迁移mp_plan_info表里的每台电梯最新的历史维保计划（DATA_STATE=0）的数据记录到mp_plan_info_his表，常规的迁移方式，会直接干爆CPU，咨询过运维，可以采用分条件分批的方式分批迁移单表数据，但是分批的条件要用到表索引，不然load数据都load不出来，研究了下mp_plan_info的索引列表，最终选取了idx_DEVICE_CODE_DATA_STATE(DEVICE_CODE,DATA_STATE)索引，采用分每个电梯下，先查找出电梯下的历史维保计划的最新创建时间，然后通过DEVICE_CODE、DATA_STATE以及CREATE_TIME的查询条件，分批迁移到mp_plan_info_his表；
-
mp_plan_info迁移数据到mp_plan_info_his表完成，需要删除mp_plan_info里的所有的历史维保计划记录，直接删除，同样也会直接干爆CPU，所以仍然采用分注册代码加DATA_STATE的查询条件去分批删除mp_plan_info表的数据，mp_plan_info只需要存储有效的维保计划记录，给表存储瘦身；
程序代码优化
-
mp_plan_info的数据记录删除要改成物理删除
-
mp_plan_info删除记录时，要先把mp_plan_info_his里对应电梯的记录全部删除，然后把当前电梯删除的维保计划批量插入到mp_plan_info_his
-
涉及到mp_plan_info批量删除的功能，需要记录业务功能日志，如修改维保计划、工单动态调整，需要记录当前维保配置的参数信息等（考虑要不要处理）
部署上线迁移处理
由于是不停库迁移表数据，同时因为是大表迁移表数据，迁移周期长，为了不影响到用户正常使用系统，所以要做好迁移步骤分析，鉴于以上分析，我们提出以下方案：
- 开始迁移前首先要备份原数据库，以防后续出现数据丢失或错乱。
- 全租户创建要迁移的表结构mp_plan_info_his表
- 全租户按条件分批迁移mp_plan_info无效的表记录到mp_plan_info_his表
- 全租户按条件分批删除mp_plan_info无效的表记录
- 迁移完成后，部署需要发版上线的程序
- 部署上线完成后，由于是先迁移数据，再部署新版本程序，需要全租户把某些电梯新产生的mp_plan_info增量无效的表数据迁移到mp_plan_info_his表，做一个增量数据补偿，保持数据的一致性
- 迁移数据完成，发版结束
预期效果
经过以上优化方案的实施，我们会达到以下预期效果：
- 涉及到mp_plan_info的查询、更新、插入性能高效
- 用户加载维保计划页面响应速度快
