【IT技术分析】
当我们优化一个系统时有时发现一种情况就是自己修改SQL索引以及分区是不能解决性能问题的这时你要考虑业务逻辑优化和表设计的重构这两点的确和设计结合的很紧密
业务逻辑优化
结合实际我们先谈谈业务逻辑优化
案例一
我们的系统一个文档模块客户点击时很慢通过性能分析是点击是去查询数据库这时系统是通过Hibernate来两步处理
计算该类型的文档数量总数
显示最新文档的前篇文档
这时显示第二步的时间是很快的只取条记录但是计算该类型的所有总数很慢系统的这时的输入是很大的(计算该类型的全部文档可能有几万篇数据)输出就一条总数这时因为业务逻辑复杂即使建立索引分区等等速度也是无法提高因为不能真正做到索引覆盖和分区消除
客户是点一下要等十几秒是不能容忍的这时可能输入数据量很大下数据库很可能采用的是hash联结而且并发用户一大数据库服务器压力很大
这时常规的优化方法是没有效果的这时我们也发现客户其实对以前比较老的数据是不关心的一般只是对近期的数据比较感兴趣所有我们就在查询时默认设定半年的时间然后在时间上设定聚集索引并默认在此时间上排序使其使用合并联结减少输入数据量结果速度有明显的提升
案例二
我们在优化一个客户系统时碰到一种情况在客户的一选择功能时客户点击一下选择相关数据这时页面要要几分钟才能出来客户很不满意这时修改sql和索引都没有办法他的输入的数据量也很大和上面一下也要计算总数和取最新前几条数据
这时我们在查询是关联了人员通过调查发现客户只对和自己相关的数据感兴趣也只是查询自己相关的数据所以这时在sql语句里增加用户id这条限制同时在增加userid的索引这样一来速度就大大提高
总结
当然以上两个案例是从输入入手减少输入和输出的数据量主要优化业务逻辑达到优化系统当然有些情况要和客户确认和说服他们有时他们不一定都认可这时要说明这样做的目的相信他们也会理解
表设计优化
表设计在我们开发系统时已经确定好的设计的确能大大提高性能我们在优化系统时碰到一个比较麻烦的问题
原文 数据库重构(一)字段合并
这条sql是判断个维度一个用户id 一个机构id一个岗位id 还有级别判断和是否公共sql语句里有个or组成查询表数据一大就表扫描性能很差但业务要求和系统要求这样判断即使在表中这五个字段都建索引速度也不会快太多OR了SQL Server 查询分析器无法优化
这时由于设计时 用户id机构id岗位id为个只有一个有数据所以将这个字段合并较少Or语句让数据库能使用索引
总结
表设计是优化是让sql语句能使用到索引或者增加冗余字段减少其输入和输出数据或者减少查询数据(如计算静态表)典型的如索引视图数据仓库等
