在性能优化项目中，我只是一个协助参与的角色，但也正好给了我从外部参看项目运作的机会，需要优化的系统已经是运行了6年的老系统，数据从来没有做过分离，涉及全库查询等致命的优化问题。另外本次项目的业主也希望对优化工作进行指导，造成走了不少弯路，同时由于垂直数据库技术不足，从外部找了合作伙伴进行深入性能优化研究。
总之这个项目虽小，但具备了复杂项目的各方面的内容，我也将会对这个项目进行初步的分析。
基础方向
SQL优化
首先要做的就是找出执行慢的SQL或业务模块，调查SQL的业务逻辑是否存在可优化的空间。
- 我们先做的是根据业务部分给出的缓慢业务，查询对应的SQL，并在测试环境中模拟运行，并记录生产环境和测试环境执行响应SQL的时间
- 将最有代表性的SQL（常用业务）的执行计划列出，并查看索引的执行情况。在本次项目中，发现执行计划没有执行设定的索引，这个关键问题也是优化的重点方向。
调整表分区
表分区一直是数据库优化的重要首选。根据业务将表按照特定的字段或特定规则进行分区，能够大大提升数据库的性能。但需要注意，分区表将影响数据的插入效率，与建立索引相同，在建立表分区的过程中要分析利弊。
数据量的增加对性能开销的影响
项目中存在测试环境与生产环境，其数据量级别不同，环境配置也不同，就会造成执行相同的SQL或业务得到相反的结果，故在性能优化的前期，要至少满足数据量的同步，这样可以实现具有相同标准的对比。
在项目中的系统，将特定表的数据调整为相同时，执行效率基本相同，这就证明：
- 性能不是造成SQL执行慢的瓶颈
- 数据量的增加会造成缓存的增加，同时效率变换与缓存大小有关，并且和命中率有关。
读写分离
由于系统的业务数据量过大，且根据需求要满足无条件限制的查询，这样就势必造成全表扫描。为了能够查询效率，必须要实现读写分离，在业务时间范围只进行读操作（对查询时限要求较低），非业务时间将数据进行同步。
关于业主
本次项目的业主，技术负责人对技术要求极为苛刻，当然这也是为了项目能够顺利进行的必要条件，如何才能顺应这样的客户，时限快速迭代，快速汇报？在项目初期，我们也走了很多弯路。
- 一味的顺应只能让自己变成无头苍蝇
- 当出现信任危机的时候，建立信任可能已经是无法挽回的事情
- 沟通频率要把握清楚，埋头苦干也要抬头看路
以上是我们在于业务沟通和处事时出现的问题，当然问题的源头也出在开始我们对项目理解不清楚。
