项目oracle优化记录

背景：公司项目从老系统迁移到新系统，由于老系统数据库表结构历史悠久，迁移过程中，技术经理同时要求迁移后的系统支持大批数据量的快速相应，以提高用户的体验。

前言：优化这个东西其实考虑的东西比较多，不能一概而论，大部分情况是针对某个点，或者某个功能，又或者是具体到某个接口的响应时间的优化。

        接下来我就针对于我对于迁移系统做了哪些具体的工作，做一个简单的小结，我主要讲一下我的思路，由于表结构或者代码部分涉及到航空行业的部门机密，未经允许不可公开，所以不能贴具体的代码或是图片了，起一个抛砖引玉的作用。希望可以帮到大家。

另外，做优化的这个需求的同时，我也去购买了《Oracle性能诊断艺术》这本书，用作一个借鉴。

言归正传，首先优化的需求是针对我们大批量数据而言的功能，其中之一的功能就是单表数据量上亿的优化，我们暂且称之为-属性表。此处声明两点：

        一：为什么需要上亿？

        该表为零件属性表，一个零件可能存在几百上千个属性。零件表数量上百万时，属性表就能上亿。

        二：为什么不考虑Mysql那样分库分表？

        领导要求，领导将我们的迁移项目对标一个法国的一个航空项目，该项目领导收到的信息是，单表支持10亿级。所以要求我们迁移系统后，先能支持单表上亿，以后再进一步优化。

        其次，Oracle单机性能很好，基本不会出现数据库down掉的情况，并且由于不是云，而是物理机部署，所以整体性能也更加稳定。目前也未出现过数据库宕机的情况。

迁移表我们是通过脚本迁移的，将所有字段，包括主外键，索引一起迁移。

该属性表也是一样，迁移过来，字段好几十个，用与不用先不论，冗余重复字段太多，这个没办法，历史遗留问题。同样，索引也有11个。光索引这一块，就和表占的空间一样了，非常臃肿。

        首先就是针对索引这块进行整理，这个就不是想当然的去删除索引。第一步就是和前端与业务讨论。以属性表为例，假如前端查询某个零件的属性，需要怎么传参进来。不同业务不同处理。如果传值为字段1+字段2+字段3来查询，后端我就相应的针对该查询建立联合索引。同样，其他业务需要单独字段1来查询也能满足。这个是需要和业务沟通。

        其次，就是将UUID的主键改为oracle自增的序列号。这点和mysql差不多，原理大家也应该知道。我就不再赘述。这个改动是因为我们业务除了根据多个字段来查，很多业务场景其实是根据ID去查询该属性，这是针对这个点的一个改动。

        再者就是表字段修改，这个没办法详细说明，大概的意思就是，例如字段7，字段8，字段9在以前的业务总使用，但是现在我们迁移后，并不会使用到，但是表结构依然有这三个字段，且也会存值，直接将不需要的字段删除，以节省空间。

        还有就是join关系，业务上面，允许适当的冗余字段以减少join操作。

        剩下的就是业务上面的优化。因为我们很多场景是需要调用公司的加密jar包来实现，查看源码后，根据相应的逻辑，优化后封装成自己的代码。主要就是减少不必要的查询，以减少数据库的压力。

        说得比较笼统，而且这篇博文我也不是写给初学者的，很多技术点我就提了一下，至于为什么要这么做，可以自己去深入研究。

写得比较宽泛，如果有不对的地方，欢迎大家指正。