性能优化项目的总结

在性能优化项目中,我只是一个协助参与的角色,但也正好给了我从外部参看项目运作的机会,需要优化的系统已经是运行了6年的老系统,数据从来没有做过分离,涉及全库查询等致命的优化问题。另外本次项目的业主也希望对优化工作进行指导,造成走了不少弯路,同时由于垂直数据库技术不足,从外部找了合作伙伴进行深入性能优化研究。
总之这个项目虽小,但具备了复杂项目的各方面的内容,我也将会对这个项目进行初步的分析。

基础方向

SQL优化

首先要做的就是找出执行慢的SQL或业务模块,调查SQL的业务逻辑是否存在可优化的空间。

  1. 我们先做的是根据业务部分给出的缓慢业务,查询对应的SQL,并在测试环境中模拟运行,并记录生产环境和测试环境执行响应SQL的时间
  2. 将最有代表性的SQL(常用业务)的执行计划列出,并查看索引的执行情况。在本次项目中,发现执行计划没有执行设定的索引,这个关键问题也是优化的重点方向。

调整表分区

表分区一直是数据库优化的重要首选。根据业务将表按照特定的字段或特定规则进行分区,能够大大提升数据库的性能。但需要注意,分区表将影响数据的插入效率,与建立索引相同,在建立表分区的过程中要分析利弊。

数据量的增加对性能开销的影响

项目中存在测试环境与生产环境,其数据量级别不同,环境配置也不同,就会造成执行相同的SQL或业务得到相反的结果,故在性能优化的前期,要至少满足数据量的同步,这样可以实现具有相同标准的对比。
在项目中的系统,将特定表的数据调整为相同时,执行效率基本相同,这就证明:

  1. 性能不是造成SQL执行慢的瓶颈
  2. 数据量的增加会造成缓存的增加,同时效率变换与缓存大小有关,并且和命中率有关。

读写分离

由于系统的业务数据量过大,且根据需求要满足无条件限制的查询,这样就势必造成全表扫描。为了能够查询效率,必须要实现读写分离,在业务时间范围只进行读操作(对查询时限要求较低),非业务时间将数据进行同步。

关于业主

本次项目的业主,技术负责人对技术要求极为苛刻,当然这也是为了项目能够顺利进行的必要条件,如何才能顺应这样的客户,时限快速迭代,快速汇报?在项目初期,我们也走了很多弯路。

  1. 一味的顺应只能让自己变成无头苍蝇
  2. 当出现信任危机的时候,建立信任可能已经是无法挽回的事情
  3. 沟通频率要把握清楚,埋头苦干也要抬头看路

以上是我们在于业务沟通和处事时出现的问题,当然问题的源头也出在开始我们对项目理解不清楚。

你可能感兴趣的:(性能优化项目的总结)