对hint的调优

实际工作中经常遇到开发人员加hint为提高数据的批处理的速度,但为了提高处理速度经常遇到并行的hint随意使用,并行不是万能的,不合理的使用只能阻碍运行速度,使用如下SQL说明并行问题
SELECT  /*+ LEADING(T1) USE_HASH(T_LGIN) PARALLEL(T1,8) */
                             T1.RPO_NO
                    ,T_LGIN.LGIN_DT
                    ,T_LGIN.USER_ID 
                    ,T_LGIN.USER_IP
                    ,T_LGIN.CLNT_IP 
                    ,T_LGIN.MAC_ADDR
                    ,T_LGIN.MENU_SYS_CD
                            ,ROW_NUMBER() OVER(PARTITION BY T1.RPO_NO ORDER BY T_LGIN.LGIN_DT DESC) RNK
                    FROM    MCS_HQ_READ.UP_RPO_TRACE_0602 T1
                            ,MCS_HQ.HI_USER_LGIN T_LGIN
                    WHERE   T_LGIN.USER_ID = T1.REQ_ID
                    AND     T_LGIN.LGIN_DT >= TRUNC(T1.REQ_DT)
                    AND     T_LGIN.LGIN_DT <= T1.REQ_DT
                    ORDER BY T1.RPO_NO
他的执行计划如下
SELECT STATEMENT, GOAL = HINT: ALL_ROWS   110412 306398 30027004  
 PX COORDINATOR       
  PX SEND QC (ORDER) SYS :TQ10003 110412 306398 30027004  
   WINDOW SORT   110412 306398 30027004  
    PX RECEIVE   110412 306398 30027004  
     PX SEND RANGE SYS :TQ10002 110412 306398 30027004  
      HASH JOIN   110412 306398 30027004 "T_LGIN"."LGIN_DT">=TRUNC(INTERNAL_FUNCTION("T1"."REQ_DT")) AND "T_LGIN"."LGIN_DT"<="T1"."REQ_DT" 
       PX RECEIVE   506 396167 20996851  
        PX SEND HASH SYS :TQ10001 506 396167 20996851  
         PX BLOCK ITERATOR   506 396167 20996851  
          TABLE ACCESS FULL MCS_HQ_READ UP_RPO_TRACE_0602 506 396167 20996851  
       BUFFER SORT       
        PX RECEIVE   109819 35155980 1582019100  
         PX SEND HASH SYS :TQ10000 109819 35155980 1582019100  
          TABLE ACCESS FULL MCS_HQ HI_USER_LGIN 109819 35155980 1582019100 
说明连个表在做HASH连接时,驱动表是被读到内存的,对驱动表再作并行,意义不大,并且并行也是消耗资源的,所以这条sql在hint的指导下运行了1分56秒,那么如果对大表做并行情况又会怎样呢

SELECT  /*+ LEADING(T1) USE_HASH(T_LGIN) PARALLEL(T_LGIN,8) */
                             T1.RPO_NO
                    ,T_LGIN.LGIN_DT
                    ,T_LGIN.USER_ID 
                    ,T_LGIN.USER_IP
                    ,T_LGIN.CLNT_IP 
                    ,T_LGIN.MAC_ADDR
                    ,T_LGIN.MENU_SYS_CD
                            ,ROW_NUMBER() OVER(PARTITION BY T1.RPO_NO ORDER BY T_LGIN.LGIN_DT DESC) RNK
                    FROM    MCS_HQ_READ.UP_RPO_TRACE_0602 T1
                            ,MCS_HQ.HI_USER_LGIN T_LGIN
                    WHERE   T_LGIN.USER_ID = T1.REQ_ID
                    AND     T_LGIN.LGIN_DT >= TRUNC(T1.REQ_DT)
                    AND     T_LGIN.LGIN_DT <= T1.REQ_DT
                    ORDER BY T1.RPO_NO

查看执行计划
SELECT STATEMENT, GOAL = HINT: ALL_ROWS   18966 306398 30027004  
 PX COORDINATOR       
  PX SEND QC (ORDER) SYS :TQ10002 18966 306398 30027004  
   WINDOW SORT   18966 306398 30027004  
    PX RECEIVE   18966 306398 30027004  
     PX SEND RANGE SYS :TQ10001 18966 306398 30027004  
      HASH JOIN   18966 306398 30027004 "T_LGIN"."LGIN_DT">=TRUNC(INTERNAL_FUNCTION("T1"."REQ_DT")) AND "T_LGIN"."LGIN_DT"<="T1"."REQ_DT" 
       BUFFER SORT       
        PX RECEIVE   3653 396167 20996851  
         PX SEND BROADCAST SYS :TQ10000 3653 396167 20996851  
          TABLE ACCESS FULL MCS_HQ_READ UP_RPO_TRACE_0602 3653 396167 20996851  
       PX BLOCK ITERATOR   15227 35155980 1582019100  
        TABLE ACCESS FULL MCS_HQ HI_USER_LGIN 15227 35155980 1582019100  

这时看到总成本18966比之前的总成本110412 小了近6倍,这说明对数据量大的表且经常从磁盘读数据的表做并行是很有益处的。这条sql的执行时间是45秒,因此对不同对象使用并行还是有分别的。

 

时间: 2024-10-01 21:49:18

对hint的调优的相关文章

使用hint来调优sql语句

最近生产发现有一个sql语句运行耗时达5000多秒. 抓出来sql_id一看,sql倒不是一个很长的语句.结构也很简单.如下. select company_code, sap_company_id   from data_company_code  where company_code not in        (SELECT distinct l9_company_code           FROM detailed_data_info_v a, refund_request b  

SQL Server调优系列玩转篇(如何利用查询提示(Hint)引导语句运行)

原文:SQL Server调优系列玩转篇(如何利用查询提示(Hint)引导语句运行) 前言 前面几篇我们分析了关于SQL Server关于性能调优的一系列内容,我把它分为两个模块. 第一个模块注重基础内容的掌握,共分6篇文章完成,内容涵盖一系列基础运算算法,详细分析了如何查看执行计划.掌握执行计划优化点,并一一列举了日常我们平常所写的T-SQL语句所会应用的运算符.我相信你平常所写的T-SQL语句在这几篇文章中都能找到相应的分解运算符. 第二个模块注重SQL Server执行T-SQL语句的时候

SQL Server调优系列玩转篇三(利用索引提示(Hint)引导语句最大优化运行)

原文:SQL Server调优系列玩转篇三(利用索引提示(Hint)引导语句最大优化运行) 前言 本篇继续玩转模块的内容,关于索引在SQL Server的位置无须多言,本篇将分析如何利用Hint引导语句充分利用索引进行运行,同样,还是希望扎实掌握前面一系列的内容,才进入本模块的内容分析. 闲言少叙,进入本篇的内容. 技术准备 数据库版本为SQL Server2012,利用微软的以前的案例库(Northwind)进行分析,部分内容也会应用微软的另一个案例库AdventureWorks. 相信了解S

《Oracle高性能SQL引擎剖析:SQL优化与调优机制详解》一2.5 执行计划中其他信息的含义

2.5 执行计划中其他信息的含义 通过DBMS_XPLAN输出执行计划,除了计划本身外,还可以获得一些其他信息帮助我们进一步分析执行计划及语句性能. 2.5.1 查询块和对象别名 在使用DBMS_XPLAN显示执行计划时,选择'ADVANCED'预定义格式作为参数或者加入'ALIAS'控制字符串,可以在输出中看到以下内容: Query Block Name / Object Alias (identified by operation id): -------------------------

这样诊断和调优,轻松与数据库&quot;timeout&quot;说再见

作者介绍 许昌永,高级DBA,微软SQL Server MVP,十年以上SQL Server使用经验.曾就职于腾讯公司,从事了六年游戏行业SQL Server数据库开发和管理.目前就职于跨境电商DX.COM三年多,负责公司SQL Server和MongoDB的数据库架构设计.高可用部署.运维管理和性能优化等工作.翻译出版了书籍<PowerShellV3--SQL Server 2012数据库自动化运维权威指南>   一.超时分析   下面是用户访问一个Web站点的常见错误:     详细错误描

MaxComputeSql性能调优

 转载自xiaorui           部分用户(尤其对外输出)使用MaxCompute(原Odps)时,由于对产品的使用层面和执行层面了解程度不同,导致提交的任务执行时间过长.占用了较多集群资源:严重的会导致失败.不仅需要投入支持同学精力协助解决.也影响了用户正常业务. 合并整理部分性能提升方法方便支持用户查询和优化Sql,提高效率:部分需要原来手动调优的如mapjoin.ppd谓词下推注意分区位置等原有的调优设置在不断衍进的产品中都已实现了自动化调优. 不同阶段的产品调优参数和细节会有不

SQL Server调优系列进阶篇(如何索引调优)

原文:SQL Server调优系列进阶篇(如何索引调优) 前言 上一篇我们分析了数据库中的统计信息的作用,我们已经了解了数据库如何通过统计信息来掌控数据库中各个表的内容分布.不清楚的童鞋可以点击参考. 作为调优系列的文章,数据库的索引肯定是不能少的了,所以本篇我们就开始分析这块内容,关于索引的基础知识就不打算深入分析了,网上一搜一片片的,本篇更侧重的是一些实战项内容展示,希望通过本篇文章各位看官能在真正的场景中找到合适的解决方法足以. 对于索引的使用,我希望的是遇到问题找到合适的解决方法就可以,

ODPS JOB 长尾问题调优

引言 上篇JOB logview 查看问题 提到长尾问题,本文深入探讨下 长尾调优的方法 概述 因为数据分布不均,导致各个节点的工作量不同,整个任务就需要等最慢的节点完成才能完成.这种问题就是长尾问题,是分布式计算里最常见的问题之一,也是典型的疑难杂症. 处理这类问题的思路就是把工作分给多个Worker去执行,而不是一个Worker单独抗下最重的那份工作.本文分享平时工作中遇到的一些典型的长尾问题的场景及其解决方案. 分类 Join长尾 Join时出现某个Key里的数据特别多的情况会出现Join

《Oracle高性能SQL引擎剖析:SQL优化与调优机制详解》一1.2 显示执行计划

1.2 显示执行计划 我们现在知道,有三个途径可以获取查询计划:v$sql_plan.dba_hist_sql_plan和PLAN_TABLE.如果需要读取一条SQL语句的执行计划,就需要知道该条语句的SQL_ID,如果该语句存在多个游标或者执行计划,则还需要知道游标的CHILD_NUMBER或计划的哈希值(可选).而无论我们通过哪个途径来获取执行计划,显示方式主要是两种:语句查询和包DBMS_XPLAN显示. 1.2.1 通过查询语句显示计划 通过查询语句从一些视图里读出执行计划并作格式化输出