你的浏览器禁用了JavaScript, 请开启后刷新浏览器获得更好的体验!
输入关键字进行搜索
搜索:
没有找到相关结果
nccloud
背景：某项目反馈部分模块节点参照极慢，耗时超过30秒。但并非所有节点都异常。
分析：基于项目反馈，排查分析业务操作录制SPR发现，为特定的2个模块的物料参考慢，普遍耗时超过30秒，SPR日志如下：
根据日志记录，显示为 读取结果集时间 比较久， 但从业务整体运行正常，其他业务响应正常的背景来看，出现网络问题的几率极低。结合DBA及性能优化专家的建议，将涉及的SQL通过创建事务模拟了临时表创建、数据插入、及查询过程。 发现最后的查询操作耗时大约30秒。
协同数据库方面的工程师分析执行计划explain analyse SQL，根据计划初步反馈 “最外面 1w * 5k 数据做join，数据量很大”
根据分析情况，调整参数，在事务中 set enable_nestloop = off; 二次执行，耗时为大约30ms
基于此得出初步的结论，可以通过hint等选择合适的表join方法。如设置 set enable_nestloop = off; 但基于实际的执行计划发现，似乎临时表中的近 1 万条记录没有正确的被分析到。故在临时表创建后进行 analyze bd_materialstock_temp ；之后在进行 set enable_nestloop = on;启用默认的场景，发现执行计划已经默认走到正常最优方案
故，借此初步得出结论：由于临时表内数据较大，且没有准确的统计信息，导致没有正确的选择join方法，建议在创建临时表后进行统计信息的收集，从而实现准确的执行计划选择。
要回复问题请先登录或注册
1 个回复
nccloud
背景：某项目反馈部分模块节点参照极慢，耗时超过30秒。但并非所有节点都异常。
分析：基于项目反馈，排查分析业务操作录制SPR发现，为特定的2个模块的物料参考慢，普遍耗时超过30秒，SPR日志如下：
根据日志记录，显示为 读取结果集时间 比较久， 但从业务整体运行正常，其他业务响应正常的背景来看，出现网络问题的几率极低。结合DBA及性能优化专家的建议，将涉及的SQL通过创建事务模拟了临时表创建、数据插入、及查询过程。 发现最后的查询操作耗时大约30秒。
协同数据库方面的工程师分析执行计划explain analyse SQL，根据计划初步反馈 “最外面 1w * 5k 数据做join，数据量很大”
根据分析情况，调整参数，在事务中 set enable_nestloop = off; 二次执行，耗时为大约30ms
基于此得出初步的结论，可以通过hint等选择合适的表join方法。如设置 set enable_nestloop = off; 但基于实际的执行计划发现，似乎临时表中的近 1 万条记录没有正确的被分析到。故在临时表创建后进行 analyze bd_materialstock_temp ；之后在进行 set enable_nestloop = on;启用默认的场景，发现执行计划已经默认走到正常最优方案
故，借此初步得出结论：由于临时表内数据较大，且没有准确的统计信息，导致没有正确的选择join方法，建议在创建临时表后进行统计信息的收集，从而实现准确的执行计划选择。