程序员优化数据库后快4s,在工位手舞足蹈,遭同事嫌弃:小白兔!
作为一名程序员,你是否有这样的体会,解决了一个问题后,感觉特别有成就感,不免会得意忘形,就像自己中了彩票一样的高兴,说实话,我有时就是这样一个习惯,不过有时也会适当的控制自己的行为,特别是在公司,最近就有一名程序员同志有这样的行为,遭到了同事的嫌弃。
据这名网友发帖称,他是在某大型互联网公司,他说的程序员是t6职级的java程序员,做模糊查询,用的是like,由于数据量较大,就把数据库搞蹦了,然后这名程序员对这个字段加了索引,效率从20s提高到了16s,然后这名程序员就在办公室手舞足蹈,于是这名网友就开始吐糟了,说什么“见识到了小白兔员工的可怕”,还有“此人极度稳定 毕业后没换过工作”,不过我纳闷了,这稳定不换工作也是毛病了?针对这名网友说的这些,我们一起看看其他网友是什么看法吧!
网友一:喜闻乐见
作者点评:意思不太明白,是对这个吐糟感觉搞笑么?
网友二:跟人家技术有啥关系,不看看表数据?表数据大那就是架构问题,大数据呢?分库分表呢,缓存呢,like不是很正常,要看具体情况
作者点评:对,我也感觉这个吐糟没吐糟到点上,为什么就凭这个说人家是小白兔员工,还说人家很稳定不换工作,这中间也没什么必然联系呀!
网友三:20秒提高到16秒 那索引大概率并没有起作用 只是因为前面执行过一次 数据块大多在cache中而已
作者点评:对于模糊查询,如果是左模糊的话,索引其实是没什么作用的,如果一个查询就用这么长时间,感觉需要考虑其他技术方案了,比如Sphinx等!
京东员工:我司吧,三年不走的都是渣渣
作者点评:这个观点有点片面哦,三年不走也可能是很优秀啊,发展的很好也是有可能的!
网友四:谁说没用的,只要不是左模糊,索性就有用。不过二十几秒提高到十几秒,基本也没太多改善,意义不大。索性关键要看区分度的值。
作者点评:没错,有时数据量过大就不再是选择数据库优化的事了,要考虑采用一些搜索相关的技术方案!
网友五:量太大了吧。不过t6如果是专职做别的呢,mysql第一次用也没什么奇怪
作者点评:这点同意,程序员主要不是做数据库的,有一些事情也没必要吐糟,有写东西没什么技术含量,就是会者不难,难着不会!
从上面看来,这名楼主网友压根就没有吐糟到正点上,列出了一个现象,说出了2个遭点,然而这个遭点与现象之间并没有什么联系,另外这名程序员的优化虽然起到了一点作用,但是并没有实质上改变,况且左模糊查询的话,索引并没有什么作用的,不论是二十秒也好,十六秒也罢,这个搜索时间都不免有点长,如果是给内部人员用还好,如果是给用户使用的话,这个体验也是很差的,况且用户量大的话,这样的效率势必对系统有很大的影响,这种情况就不再是优化数据库的事情了,需要采取一些其他技术方案了,比如借助一些搜索引擎技术来解决这类问题,这样才能从根本上解决现有的痛点。
以上所有图片均来之互联网
大家好,我是“上世是朵花”。如果你有什么好的看法或者观点可以在评论区展现你的才华,互动交流,如果想进一步了解我,那就关注我吧!