过早的优化是万恶之源

“过早的优化是万恶之源”,这句话或多或少在哪听过,不过为什么优化也会带来问题,恐怕只有经历过的人才能理解其中的意义。

关于程序优化,产品优化这些词在开发工作中一定有经历过。某位程序员做事一丝不苟,对程序开发特别注重性能问题,花大量时间来优化某段代码。某位产品在提出需求的时候总是有一些目前用不到的功能,说是为了方便将来扩展。

那么实际工作中这种优化到底起到了什么作用?个人认为弊多于利。

问题一:过早引入新技术

甲同学在做一个员工日常工作内容列表的接口时,认为该接口会产生性能问题,将来数据增多的时候会有性能瓶颈,于是利用了某项缓存技术,觉得缓存一定比直接查数据库速度快,于是就引入了缓存数据库。把数据拉到缓存中,先从缓存中读取数据,没有数据的时候从数据库中读取放到缓存中。这个思路看似挺好,不过为了更新数据就设置过期时间为1天。上线后发现很多员工的日常工作内容一天内会有变化,就设置过期时间为半天,结果半天过期时间还是会有部分员工工作内容更新频繁。这时候就有些纠结了,到底是再降低过期时间还是单独更新某个员工的数据?如果选择降低过期时间会导致所有数据都要从数据库重新拉取,选择单独更新又要对各个更新几口进行修改来更新缓存。这期间不免要折腾几回来适应业务需求,而且容易造成各个业务过度依赖缓存,为了保持缓存数据一致性需要做很多工作,然而很多的工作目的并没有提高系统可用性。

问题二:过早优化数据库

有些同学在设计数据库的时候总喜欢多加些字段,为了方便未来使用,知道索引能加速查询,就使劲加索引,这基本属于不够成熟的思想,试问:等真正需要字段的时候加会晚吗?现在提前加了后面还能知道这个字段当初是准备怎么用来的吗?别的同学要加的时候发现已经有了一个类似的,这个字段到底有没有在用,不敢删又不敢用。索引加了一大堆本以为有积极作用,可不知道索引会占用空间,插入修改却慢了下来。

问题三:过早进行防范准备

在没有真实QPS数据和准确预估的情况,开发同学生生怕线上出现故障,要求多部署几台服务器做负载均衡,反正服务器多了也不会有问题。但是过多的服务器会带来其他方面的问题: 1、运维难度增加 2、企业成本增加 3、线上故障排查难度增加

针对性优化

在避免过度设计的情况下才进行针对性优化。性能问题的出现并不是经常性的,而是在某个访问高峰期出现,这时候影响范围还不是很大,但是该考虑进行优化了,如果是经常性突发并发数增加可以考虑缓存数据库。如果是日常单机承载能力高可以进行一定压力测试,评估并发压力增加合适的服务器。随着企业发展,数据量不断累积,此时数据库成为主要压力,此时对数据库索引,SQL进行优化,往往能有立竿见影的效果。

总结:没有针对性的性能优化,只是按照假象场景来设计,最后不但不能起到优化作用反而为后期优化带来累赘。