复杂SQL 查询调优

2015-12-23 04:52:06 346 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›
nomic nomic 墨衍会员 · AI 创作全网分发 墨衍智能分发 通过墨衍一键同步至各平台 可同步平台 CSDN微信公众号微博知乎掘金百家号博客园抖音小红书 你的文章也可以这样分发 墨衍会员 ¥399起/年，写一次发全网 我也要 + 加入社区
TiDB 的调优：让你的 TiDB 集群跑得更快 •硬件配置：确保 TiDB 和 TiKV 节点有足够的计算和存储资源，尤其是 SSD 存储和高速网络。•SQL 优化：合理创建索引，避免全表扫描，减少不必要的查询。•事务调优：关注分布式事务的性能，避免长事务和高并发事务。•TiKV 存储引擎：根据实际负载调整 TiKV 的内存、磁盘和 RocksDB 配置。•监控：利用 TiDB Dashboard 和慢查询日志等工具，实时监控系统性能，及时发现并解决瓶颈。通过这些调优措施，你可以让 TiDB 在高并发、大数据量的场景下表现得更加高效。 阅读详情
原本写好的SQL脚本是这样的：
SELECT /*+ PARALLEL (PR, 5)*/
PR.PURCH_REQ_ID,
PR.PURCH_REQ_ITM_NR,
PO.PO_NR,
PO.PO_ITM_NR,
PR.PURCH_REQ_ITM_SRC_SYS_KY,
PR.EFF_FRM_GMT_TS AS PREQ_EFF_FRM_GMT_TS,
PR.PURCH_REQ_CRT_TS,
PR.H_LGCL_DEL_IND AS PREQ_H_LGCL_DEL_IND,
PR.D_LGCL_DEL_IND AS PREQ_D_LGCL_DEL_IND,
PO.MFG_PTNR_SITE_ID,
PR.PROD_ID,
PR.PRE_DTF_CUST_CR_CHK_STAT_CD,
PR.PURCH_REQ_PART_STAT_CD,
PR.PLNT_CD,
PR.SO_ID,
PR.SO_LN_ITM_ID,
PR.SCH_LN_ITM_ID,
PR.PURCH_REQ_ITM_QT,
PO.SRC_SYS_KY AS PO_SRC_SYS_KY,
PO.EFF_FRM_GMT_TS AS PO_EFF_FRM_GMT_TS,
PO.PURCH_ORG_CD,
PO.PO_CRT_TS,
PO.PO_ITM_QT,
PO.PO_LN_ITM_DLVR_TX,
PO.H_LGCL_DEL_IND AS PO_H_LGCL_DEL_IND,
PO.D_LGCL_DEL_IND AS PO_D_LGCL_DEL_IND,
ACK_ASN_MAX.PO_ACK_ITM_EXT_DOC_ID,
ACK_ASN_MAX.PO_ACK_EFF_FRM_GMT_TS,
ACK_ASN_MAX.PACK_ID,
ACK_ASN_MAX.ADV_SHIP_NOTIF_ID,
ACK_ASN_MAX.PO_LA_CRT_DT ,
ACK_ASN_MAX.PO_LA_DT ,
ACK_ASN_MAX.PO_LA_QT ,
ACK_AB.PO_AB_CRT_DT ,
ACK_AB.PO_AB_DT ,
ACK_AB.PO_AB_QT ,
ACK_WI.PO_WI_CRT_DT ,
ACK_WI.PO_WI_DT ,
ACK_WI.PO_WI_QT
FROM
SCO.PURCH_REQ_LC_LE PR
JOIN
SCO.PO_LC_LE PO
ON
PR.PURCH_REQ_ID = PO.H_PURCH_REQ_ID
AND PR.PURCH_REQ_ITM_SRC_SYS_KY = PO.PURCH_REQ_ITM_SRC_SYS_KY
JOIN
(
SELECT /*+ PARALLEL (ASN, 5)*/
ACK_MAX.PO_NR,
ACK_MAX.PO_ITM_NR,
ACK_MAX.PO_ACK_ITM_EXT_DOC_ID,
ACK_MAX.EFF_FRM_GMT_TS AS PO_ACK_EFF_FRM_GMT_TS,
ACK_MAX.SRC_SYS_KY,
ASN.PACK_ID,
ASN.ADV_SHIP_NOTIF_ID,
TRUNC(ASN.ADV_SHIP_NOTIF_CRT_TS) AS PO_LA_CRT_DT,
TRUNC(ASN.ADV_SHIP_NOTIF_DLVR_TS) AS PO_LA_DT,
ASN.ADV_SHIP_NOTIF_ITM_QT AS PO_LA_QT
FROM
SCO.ADV_SHIP_NOTIF_LC_LE ASN
JOIN
(
SELECT
PO_NR,
PO_ITM_NR,
SRC_SYS_KY,
MAX(PO_ACK_ITM_EXT_DOC_ID) AS PO_ACK_ITM_EXT_DOC_ID,
EFF_FRM_GMT_TS
FROM
SCO.PO_ACK_LC_LE
WHERE
(
PO_NR, PO_ITM_NR, EFF_FRM_GMT_TS) IN
(
SELECT
PO_NR,
PO_ITM_NR,
MAX(EFF_FRM_GMT_TS)
FROM
SCO.PO_ACK_LC_LE
GROUP BY
PO_NR,
PO_ITM_NR)
GROUP BY PO_NR,
PO_ITM_NR,
SRC_SYS_KY,
EFF_FRM_GMT_TS) ACK_MAX
ON
ASN.PO_NR = ACK_MAX.PO_NR
AND ASN.PO_ITM_NR = ACK_MAX.PO_ITM_NR
AND ASN.SRC_SYS_KY = ACK_MAX.SRC_SYS_KY) ACK_ASN_MAX
ON
PO.PO_NR = ACK_ASN_MAX.PO_NR
AND PO.PO_ITM_NR = ACK_ASN_MAX.PO_ITM_NR
AND PO.SRC_SYS_KY = ACK_ASN_MAX.SRC_SYS_KY
JOIN
(
SELECT /*+ PARALLEL (ACK, 5)*/
ACK.PO_NR,
ACK.PO_ITM_NR,
SRC_SYS_KY,
TRUNC(ACK.PO_ACK_ITM_CRT_TS) AS PO_AB_CRT_DT,
TRUNC(ACK.PO_ACK_ITM_VNDR_CONF_TS) AS PO_AB_DT,
ACK.PO_ACK_ITM_QT AS PO_AB_QT
FROM
SCO.PO_ACK_LC_LE ACK
WHERE
ACK.PO_ACK_ITM_CONF_CATG_CD = 'AB') ACK_AB
ON
PO.PO_NR = ACK_AB.PO_NR
AND PO.PO_ITM_NR = ACK_AB.PO_ITM_NR
AND PO.SRC_SYS_KY = ACK_AB.SRC_SYS_KY
JOIN
(
SELECT /*+ PARALLEL (ACK, 5)*/
ACK.PO_NR,
ACK.PO_ITM_NR,
SRC_SYS_KY,
TRUNC(ACK.PO_ACK_ITM_CRT_TS) AS PO_WI_CRT_DT,
TRUNC(ACK.PO_ACK_ITM_VNDR_CONF_TS) AS PO_WI_DT,
ACK.PO_ACK_ITM_QT AS PO_WI_QT
FROM
SCO.PO_ACK_LC_LE ACK
WHERE
ACK.PO_ACK_ITM_CONF_CATG_CD = 'WI') ACK_WI
ON
PO.PO_NR = ACK_WI.PO_NR
AND PO.PO_ITM_NR = ACK_WI.PO_ITM_NR
AND PO.SRC_SYS_KY = ACK_WI.SRC_SYS_KY;

执行计划是这样的：
---------------------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
---------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 8136 | 3456K| | 35106 (13)| 00:05:36 | | | |
| 1 | PX COORDINATOR | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10001 | | | | | | Q1,01 | P->S | QC (RAND) |
| 3 | NESTED LOOPS | | | | | | | Q1,01 | PCWP | |
| 4 | NESTED LOOPS | | 8136 | 3456K| | 35106 (13)| 00:05:36 | Q1,01 | PCWP | |
| 5 | NESTED LOOPS | | 737 | 245K| | 34142 (14)| 00:05:27 | Q1,01 | PCWP | |
| 6 | NESTED LOOPS | | 347 | 99K| | 33945 (14)| 00:05:25 | Q1,01 | PCWP | |
| 7 | NESTED LOOPS | | 294 | 73206 | | 33778 (14)| 00:05:23 | Q1,01 | PCWP | |
|* 8 | HASH JOIN | | 510 | 73950 | | 33595 (14)| 00:05:21 | Q1,01 | PCWP | |
| 9 | BUFFER SORT | | | | | | | Q1,01 | PCWC | |
| 10 | PX RECEIVE | | 1676 | 127K| | 32966 (14)| 00:05:15 | Q1,01 | PCWP | |
| 11 | PX SEND BROADCAST | :TQ10000 | 1676 | 127K| | 32966 (14)| 00:05:15 | | S->P | BROADCAST |
| 12 | VIEW | | 1676 | 127K| | 32966 (14)| 00:05:15 | | | |
| 13 | HASH GROUP BY | | 1676 | 92180 | | 32966 (14)| 00:05:15 | | | |
| 14 | VIEW | VM_NWVW_2 | 1676 | 92180 | | 32966 (14)| 00:05:15 | | | |
|* 15 | FILTER | | | | | | | | | |
| 16 | HASH GROUP BY | | 1676 | 114K| | 32966 (14)| 00:05:15 | | | |
|* 17 | HASH JOIN | | 31M| 2104M| 505M| 29531 (4)| 00:04:43 | | | |
| 18 | INDEX FAST FULL SCAN| PO_ACK_LC_LE_XIE8 | 14M| 341M| | 2615 (6)| 00:00:25 | | | |
| 19 | INDEX FAST FULL SCAN| PO_ACK_LC_LE_XIE9 | 14M| 614M| | 3177 (5)| 00:00:31 | | | |
| 20 | PX BLOCK ITERATOR | | 3471K| 221M| | 622 (6)| 00:00:06 | Q1,01 | PCWC | |
| 21 | TABLE ACCESS FULL | ADV_SHIP_NOTIF_LC_LE | 3471K| 221M| | 622 (6)| 00:00:06 | Q1,01 | PCWP | |
| 22 | TABLE ACCESS BY INDEX ROWID | PO_LC_LE | 1 | 104 | | 2 (0)| 00:00:01 | Q1,01 | PCWP | |
|* 23 | INDEX UNIQUE SCAN | PO_LC_LE_XPK | 2 | | | 1 (0)| 00:00:01 | Q1,01 | PCWP | |
|* 24 | TABLE ACCESS BY INDEX ROWID | PO_ACK_LC_LE | 1 | 46 | | 3 (0)| 00:00:01 | Q1,01 | PCWP | |
|* 25 | INDEX RANGE SCAN | PO_ACK_LC_LE_XIE9 | 1 | | | 2 (0)| 00:00:01 | Q1,01 | PCWP | |
|* 26 | TABLE ACCESS BY INDEX ROWID | PO_ACK_LC_LE | 2 | 92 | | 3 (0)| 00:00:01 | Q1,01 | PCWP | |
|* 27 | INDEX RANGE SCAN | PO_ACK_LC_LE_XIE9 | 1 | | | 2 (0)| 00:00:01 | Q1,01 | PCWP | |
|* 28 | INDEX RANGE SCAN | PURCH_REQ_LC_LE_XIE8 | 15 | | | 2 (0)| 00:00:01 | Q1,01 | PCWP | |
| 29 | TABLE ACCESS BY INDEX ROWID | PURCH_REQ_LC_LE | 11 | 1034 | | 11 (0)| 00:00:01 | Q1,01 | PCWP | |
---------------------------------------------------------------------------------------------------------------------------------------------------

由于这些表的数量都非常大，需要进一步调优这个查询，请大家给点建议。
多谢
...全文
大数据从业者必知必会的Hive SQL调优技巧 | 京东云技术团队 在HDFS中，每个小文件对象约占150字节的元数据空间，如果有大量的小文件存在，将会占用大量的内存资源。根据集群的配置和资源情况，合理调整Hive查询的并行度和资源分配，可以提高查询的并发性和整体性能。COUNT DISTINCT操作需要用一个Reduce Task来完成，这一个Reduce需要处理的数据量太大，就会导致整个Job很难完成，一般COUNT DISTINCT使用先GROUP BY再COUNT的方式替换，虽然会多用一个Job来完成，但在数据量大的情况下，这个绝对是值得的。 阅读详情

相关推荐

【数据库优化】基于SQL高级策略的性能调优：毕业设计中复杂查询优化与实战应用

内容概要：本文围绕“SQL语句优化实战技巧在毕业设计中的应用”，系统介绍了高级优化策略与性能调优方法，涵盖窗口函数、CTE、分区表设计、物化视图、查询缓存及执行计划引导等核心技术。通过科研经费统计系统的实际案例，对比优化前后SQL执行效率，展示了从全表扫描耗时8.7秒到优化后仅0.8秒的显著提升，性能提高约11倍。文章还列举了在毕业论文管理系统、科研项目管理、校园卡消费报表等多个高校信息系统中的应用场景，体现了SQL优化在真实项目中的广泛适用性。; 适合人群：计算机及相关专业本科高年级学生、正在进行毕业设计或数据库课程设计的学生，以及希望提升SQL实战能力的初级开发者；具备基本SQL语法和数据库理论知识者更佳； 使用场景及目标：①应对毕业设计中复杂的多表关联查询与统计分析性能瓶颈；②掌握如何通过分区表、物化视图等手段提升查询响应速度；③学习执行计划调优与HINT提示的使用，深入理解数据库优化器行为； 阅读建议：建议读者结合主流数据库平台（如MySQL、Oracle）动手实践文中代码案例，重点关注分区表创建、物化视图刷新机制与窗口函数的替代优势，同时对比不同优化策略的执行计划差异，全面提升SQL性能调优的实战能力。

matlab@com

【数据库优化】基于SQL执行计划与复合索引的复杂查询性能调优：多表连接与窗口函数实战

内容概要：本文系统讲解了SQL复杂查询的编写与优化技术，涵盖多表连接、窗口函数、执行计划解读及索引设计等核心主题。通过实际案例分析性能瓶颈，介绍索引优化、驱动表选择、CTE重构、覆盖索引、游标分页、物化视图等关键技术，并结合EXPLAIN工具和可视化平台（如DBeaver）进行执行计划分析，帮助读者掌握从诊断到优化的完整流程。文中还对比了MySQL、PostgreSQL、Oracle等数据库在执行计划上的差异，提供了跨系统适配建议。; 适合人群：具备一定SQL基础，从事数据库开发、运维或数据分析工作1-3年的技术人员；需要优化复杂查询性能的后端研发与DBA人员。; 使用场景及目标：①解决多表JOIN导致的慢查询问题；②利用窗口函数替代低效的自连接实现高性能分析；③通过执行计划精准定位全表扫描、临时表、排序等性能瓶颈；④设计高效复合索引并规避常见索引失效场景； 阅读建议：建议结合实际数据库环境动手实践文中的优化案例，重点关注执行计划的变化与性能指标对比，逐步掌握从问题识别到方案落地的系统化调优方法。

梵得儿SHI

【数据库优化】达梦SQL并行查询与Hint调优技术在计算机竞赛中的应用：复杂关联分析性能提升策略

内容概要：本文深入探讨了达梦数据库在计算机竞赛中面对大规模数据处理时的SQL进阶优化技巧，重点介绍并行查询与Hint提示的深度调优方法。通过实际案例展示如何利用PARALLEL Hint提升多核资源利用率，实现数据并行扫描与处理，并结合LEADING和USE_HASH Hint强制优化器选择最优执行计划，将原本低效的串行MERGE JOIN优化为高效的并行HASH JOIN，显著缩短查询响应时间。文章还强调了统计信息收集的重要性，并详细解析了优化后的执行流程，包括并行扫描、哈希连接、预聚合等环节，体现了对数据库底层机制的深刻理解。; 适合人群：熟悉SQL基本语法与执行计划分析，具备一定数据库调优经验，参与高性能计算或数据库类竞赛的技术人员或学生；尤其适合备战涉及海量数据处理场景的计算机竞赛选手。; 使用场景及目标：①解决大表JOIN性能瓶颈问题；②在竞赛环境中通过Hint精确控制执行计划，突破优化器默认策略局限；③结合并行查询最大化硬件资源利用率，达成极限性能优化目标； 阅读建议：学习时应结合达梦数据库的执行计划工具（如EXPLAIN）对比优化前后差异，动手实践Hint语法与并行参数设置，并深入理解不同连接方式的适用条件与资源消耗特点，从而掌握在高压环境下快速诊断与调优复杂SQL的能力。

数智顾问

【数据库优化】基于达梦SQL性能调优技术：复杂查询场景下递归与窗口函数的代码级优化策略研究

内容概要：本文深入探讨了达梦数据库SQL优化技巧在计算机竞赛复杂查询场景中的实际应用，重点解析了递归查询、窗口函数、多维度聚合等高性能挑战问题的解决方案。通过具体案例对比原始低效SQL与优化后SQL的执行效率，展示了如何利用达梦数据库的CONNECT BY递归优化、索引引导、物化视图、向量化执行引擎等特性，将原本超时的查询优化至毫秒级响应，全面提升复杂查询性能。; 适合人群：具备一定SQL基础，参与计算机竞赛或从事数据库开发、需要处理大规模数据查询优化的1-3年经验开发者或参赛选手。; 使用场景及目标：①应对竞赛中树形结构查询、滑动窗口统计、多步聚合等复杂SQL性能瓶颈；②掌握达梦数据库特有的优化手段如递归控制、索引设计、执行计划分析，实现从“超时”到“高效”的性能跃迁；③理解数据库底层机制以支持算法类题目的工程化落地。; 阅读建议：此资源强调实战与底层原理结合，建议读者在学习过程中动手实践代码案例，结合EXPLAIN分析执行计划，深入理解索引、递归、聚合等操作的优化逻辑，并尝试迁移至其他类似数据库场景中进行验证与拓展。

数字化顾问

【数据库优化】基于SQL查询性能调优：复杂多表连接与索引设计在电商订单分析中的应用

内容概要：本文系统讲解了SQL语句优化的核心技术与实战方法，涵盖多表连接优化、窗口函数应用、执行计划解读和索引设计四大核心维度。通过具体SQL示例对比优化前后性能差异，深入剖析JOIN顺序、CTE预过滤、窗口函数替代自连接、执行计划关键指标（如type、key、Extra）分析，以及复合索引的最左匹配、覆盖索引、ICP优化等关键技术。结合电商订单分析等真实场景，提供从查询重写到索引重构的完整优化方案，并给出涵盖开发、测试、部署、监控全流程的SQL优化检查清单，帮助开发者显著提升复杂查询性能。; 适合人群：具备一定SQL基础，从事数据库开发、数据分析或后端研发工作1-3年的技术人员。; 使用场景及目标：①解决复杂查询响应慢的问题，提升SQL执行效率；②掌握执行计划分析技能，精准定位性能瓶颈；③设计高效的索引策略，优化数据库整体性能；④在开发流程中规范化SQL编写与审核。; 阅读建议：此资源强调实战导向，建议结合实际数据库环境动手实践文中示例，使用EXPLAIN验证优化效果，并在测试环境中模拟生产数据量进行性能对比，深入理解每项优化原则背后的原理。

Between bytes
评论 6
收藏 已收藏
分享
返回顶部
nomic
nomic
Oracle 高级技术 3,499 成员 18,710 内容
+ 加入社区