前言
注:这里讨论的场景在于MIS,OA一类的系统
大部分同学在看到这个问题的时候,第一反应是糟糕的SQL语句,没有加索引,这甚至已经成为一种惯性思维。
当发现性能出问题的时候,一般都会想到加个索引,或者改造下连接方式,去掉“not exists”诸如此类,但效果往往不太理想,或过一段时间后,效果又不理想了,此时,一般大家都会觉得问题在于自己还不是大神。
正文
今天给大家分享的就是:为了提高性能,不是大神的我们还有多少方法可以采取?
性能有三大杀手:1)糟糕的SQL使用;2)糟糕的数据结构;3)糟糕的业务模型
下面举一个实际的例子,在EPO物资采购系统中的需求跟踪功能中,可以查询到所有历史提交的需求申请单。查询包含从需求申请->需求受理->订单->验收入库->通知领用->发放完成所有环节的状态。最初的做法是通过join将需求表、需求受理表、订单表、验收表、领用通知表和发放表连接起来形成一张视图。当数据量小的时候,看起来一切都是那么的完美,但是后来就不那么美好了。于是,后来我们采取了一系列的优化。
阶段一:物化视图
当join的时候,问题出现在join的计算过程,数据量大了,计算耗费就会大,性能便会下降。不过,当问题来的那天,对于这种问题,大家是非常坦然的面对,做一张物化视图就可以了,每天晚上计算一下