数据库视图删除——从不同角度寻找解决问题最高效的方案

版权声明：本文为博主原创文章，未经博主允许不得转载。

从不同角度寻找解决问题最高效的方案

背景

某个MySQL库中存在历史遗留的不符合规范的视图，DBA联系到各个业务方要清理不合规的视图。我们组项目共涉及到三个视图。

解决方案

① 修改项目，删除视图

首先想到的解决方案是，查各个视图在项目代码里面的使用情况，及业务上该视图的数据是否有用。
若视图涉及的数据已不再使用，则直接在项目里面把该视图的查询语句下掉，QA回归项目，上线后删除视图。
若数据仍有效，只能在项目里面把涉及到的视图语句替换为视图的定义语句，QA回归项目，上线后删除视图。

成本

三个视图涉及的项目已知的有两个，项目1 和 项目2。
项目1 一直处于维护状态，逻辑梳理、代码更改、QA回归测试、上线，这几个流程下来需要一天时间。
而项目2已处于逐步迁移且项目代码无人维护的状态，成本未知。

风险

1. 视图存在时间较长，各业务方使用情况未知，贸然删视图，可能会导致线上查询故障
2. 项目2 修改上线成本未知

② 删除视图，建同名表

由于第一种解决方案成本高、风险大，尝试换个角度解决该问题。
分析三个视图的定义语句可知，其中两个视图都是只有一条数据；另外一个视图是对表的简单查询，数据量不大，且引用的表已经有一段时间没有更新了。
这三个视图均处于废弃的边缘，保证可以继续使用，不出错即可，花大量成本去维护没有任何意义。
因此可以采用先删除视图，用原视图的定义语句新建同名表。

优势

1. 极大较小维护成本，写SQL语句，自测，联系DBA执行，总耗时一小时
2. 风险最小化，不用考虑遗漏其他业务方调用；建同名表后，原来查视图的语句即切换到查表，此过程对各个业务无感知
   （背景知识：MySQL的同一库下表和视图名称不能相同，表和视图的查询方式相同）

---

--------------------------文档信息--------------------------
版权声明：本文为博主原创文章，未经博主允许不得转载
署名(BY) ：dkjkls（dkj卡洛斯）
文章出处：http://blog.csdn.net/dkjkls