遇到问题:项目列表数据查询之后需要通过字典翻译,当数据量上千的时候响应效率竟然高达好几秒,更别说上万了。
查找根源:通过追踪源码,发现数据字典翻译时,是通过反射对数据进行get/set。
处理过程:
一.通过修改查询sql进行join,直接查出数据字典要翻译的值。
二.现实是,数据字典不在同一个数据库,而且在数据库中处理大数据量数据翻译也是不建议的。那么只能自己重写翻译逻辑。
- 通过测试map的get过程效率可以满足当前需要
- 查询出所有涉及的数据字典项和翻译值,并存到map当中,格式为:
{ ”filed1“:{ "类别标识1":"要翻译的值1", ... }, ”filed2“:{ "类别标识1":"要翻译的值1", ... } } - 改造sql FILED1 as filed1
- 查询结果返回list
- 遍历查询结果list,在根据每一行的数据进行分析需要转化的数据字典值,重新赋值
- 输出新的list
处理结果:效率大幅提升,满足应用要求
本文探讨了一个项目中遇到的问题,即在数据量上千时,通过反射进行数据字典翻译导致响应时间过长。作者通过追踪源码,发现效率瓶颈并提出两种解决策略:一是尝试修改SQL进行JOIN操作,二是将所有数据字典项翻译值预加载到内存中的Map。由于数据字典不在同一数据库,作者选择了后者,通过构建翻译Map,改造SQL并遍历查询结果,显著提升了效率,满足了应用需求。

264

被折叠的 条评论
为什么被折叠?



