面向集合的思维来优化PL/SQL过程
背景：
用户表users, 每个用户都有count 属性，每天给用户统计的时候,原来使用的方法是：
for lr_user in (select..... from users) loop
lr_user.count = f_get_count(...)
..... ---其他逻辑
end loop;
问题：
随着users和其他关联表 的增大， 上面的循环花的时间越来越长，有一次竟然长达2个小时，分析AWR报告发现，时间主要消耗在f_get_count函数里面，后来多次优化f_get_count里面的SQL，虽然时间有所减少，但是过一段时间又增长了。
优化SQL达不到效果，只能往逻辑方面思考，因为时间主要是花在f_get_count里面，所以能减少f_get_count的调用次数那是最好的。后来想到能不能建个临时表，先保存每个用户的count, 使用的时候直接从表里面取，经过实践，花的时间从2小时减到20多分钟，并且用户增长带来的影响也大大减少！
结论： SQL 本身就是一门面向集合的语言，能一次执行解决的问题，绝大多数都比使用PL/SQL过程控制性能要好得多！
用户表users, 每个用户都有count 属性，每天给用户统计的时候,原来使用的方法是：
for lr_user in (select..... from users) loop
lr_user.count = f_get_count(...)
..... ---其他逻辑
end loop;
问题：
随着users和其他关联表 的增大， 上面的循环花的时间越来越长，有一次竟然长达2个小时，分析AWR报告发现，时间主要消耗在f_get_count函数里面，后来多次优化f_get_count里面的SQL，虽然时间有所减少，但是过一段时间又增长了。
优化SQL达不到效果，只能往逻辑方面思考，因为时间主要是花在f_get_count里面，所以能减少f_get_count的调用次数那是最好的。后来想到能不能建个临时表，先保存每个用户的count, 使用的时候直接从表里面取，经过实践，花的时间从2小时减到20多分钟，并且用户增长带来的影响也大大减少！
结论： SQL 本身就是一门面向集合的语言，能一次执行解决的问题，绝大多数都比使用PL/SQL过程控制性能要好得多！
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/30741760/viewspace-2098123/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
没有了~
请登录后发表评论
登录
全部评论
