一次postgresql效率优化过程
之前在做项目的时候遇到一个性能问题，每每想起都心有余悸，记下来以作前车之鉴。问题描述：
前台调用查询测试用例库的树数据，如果库下的用例集数量较多，同时用例集层级深时，查询耗时超过5秒甚至10秒（postgresql）。
问题分析：
通过分析查询的SQL语句发现，在执行查询的时候，会通过递归去查询统计每一个用例集直到最上级用例库中的测试用例数量，数据量大时时间开销自然就大了。
解决方案:
单纯从SQL入手，对于性能的影响不大，因此考虑到将统计放到其它地方，此处只作查询处理。对于一个用例库来说，80%的操作是查询，剩下的才是创建测试用例，统计数量的过程如果放到用户较少遇到的操作中，对用户的影响就降到了最低。
解决步骤如下：
1、用例库表增加三列：有效用例数、无效用例数、草稿用例数。用于保存每个用例集下的用例数量；
2、修改创建测试用例逻辑。创建用例后实时计算当前用例所在的用例集以及上级所含有的用例数量，更新到用例库表中；
3、修改查询用例库树的SQL。去掉之前的统计计算过程，直接取对应的字段即可。
再次查询用例库树，查询效率大大提高，从之前的5~10秒提高到现在毫秒级，bingo。
最后的反思——将性能开销较大的操作放到用户百分之二十或者更少的操作中，查询则尽可能避免递归统计等耗时操作（递归是个好东西，但要慎用），而此处创建用例时，只更新当前操作用例集所在的节点，对创建的效率也并无多少影响。而增加了三列，对于整个性能的提升起了非常大的作用，适当的增加“冗余”列，带来的却是莫大的方便，值！
看了LZ的帖子，我只想说一句很好很强大！
页:
[1]