一條大sql的調優
這是某個DW應用裡的大sql,原來據說5分鐘就執行完了,現在居然要5個小時,看看情況吧:
SELECT r_Time.time_id,
ae.accounting_entity_id,
cs.vendor_id,
ai.account_item_id,
ta.target_account_id,
rf.previous_balance PERIOD_BEGIN_BALANCES,
rf.balance PERIOD_net_BALANCES
FROM (
-- Part 1/2, Uncleared & overdue documents when it's calaculation day
SELECT bsik.shkzg,
bsik.dmbtr,
bsik.zfbdt,
bsik.bukrs,
bsik.hkont,
bsik.source_code,
bsik.blart,
bsik.lifnr,
bsik.gjahr,
bsik.monat,
bsik.belnr,
bsik.augdt,
bsik.budat
FROM myods_bsik bsik
WHERE
-- calaculation day is later than GL date
bsik.budat < to_date(to_char(r_Time.time_id), 'yyyymmdd') + 1
UNION ALL
-- Part 2/2, Althouth already cleared now, still uncleared & overdue documents
-- when it's calaculation day
SELECT bsak.shkzg,
bsak.dmbtr,
bsak.zfbdt,
bsak.bukrs,
bsak.hkont,
bsak.source_code,
bsak.blart,
bsak.lifnr,
bsak.gjahr,
bsak.monat,
bsak.belnr,
bsak.augdt,
bsak.budat
FROM myods_bsak bsak
WHERE
bsak.budat < to_date(to_char(r_Time.time_id), 'yyyymmdd') + 1
AND bsak.augdt >= to_date(to_char(p_time_id) ,'yyyymmdd')
) bsak
,
target_account_dim ta,
accounting_item_dim ai,
accounting_entity_dim ae,
vendor_dim cs,
(SELECT ag.aging_id,
ag.aging_name,
to_number(ag.attribute1) start_days,
nvl(to_number(ag.attribute2), 1e100) end_days
FROM dwdim.aging_dim ag
WHERE ag.aging_id >= 1002) ag,
(select *
from my_report_01_fact rf
where rf.time_id = r_Time.time_id) rf
WHERE ta.corporation_code = CASE(bsak.bukrs) WHEN '1000' THEN('E2100') ELSE('E2000') END
AND ta.mapping_account_code = bsak.hkont
AND cs.vendor_code = bsak.lifnr
AND ta.standard_account_code = ai.standard_account_code
AND ae.corporation_code = bsak.source_code
and rf.vendor_id = cs.vendor_id(+)
and rf.accounting_entity_id = ae.accounting_entity_id(+)
and rf.target_account_id = ta.target_account_id(+)
and rf.account_item_id = ai.account_item_id(+)
AND ta.set_of_books_code = '2'
AND CS.CORP_CODE = '81000'
AND cs.set_of_books_code = '2'
and (to_date(to_char(r_Time.time_id), 'yyyymmdd') - bsak.budat) between ag.start_days and ag.end_days
group by ae.accounting_entity_id,
cs.vendor_id,
ai.account_item_id,
ta.target_account_id,
rf.previous_balance,
rf.balance
簡單看了一下,用了這麼多左連線,想快都難。缺兩個索引,先把bsak.budat和rf.time_id建上索引,執行速度降為10分鐘,從資料量上來看bsik表資料量非常小,只幾萬條,但v$session_longops裡卻顯示tsc速度非常慢,檢視其塊數,hwm下差不多幾萬個資料塊,跟記錄數基本上1:1的關係。暈倒,難道用了insert/*+append*/?不管它了,alter table bsik move;一把吧,塊數降到了1000,再執行,50秒。
[@more@]
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/112417/viewspace-980335/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 大廠都是怎麼SQL調優的?SQL
- SQL Server一次SQL調優案例SQLServer
- SQL 調優一般思路SQL
- [20181114]一條sql語句的優化.txtSQL優化
- 大廠是怎麼進行SQL調優的?SQL
- 記一次SQL Server刪除SQL調優SQLServer
- 記一次SQL調優過程SQL
- MySQL調優篇 | SQL調優實戰(5)MySql
- 對一條基於分割槽的簡單SQL的優化SQL優化
- Oracle SQL調優系列之SQL Monitor ReportOracleSQL
- 一次SQL調優 聊一聊 SQLSERVER 資料頁SQLServer
- PostgreSQL技術大講堂 - 第31講:SQL調優技巧SQL
- Oracle SQL效能優化的40條軍規OracleSQL優化
- Oracle 效能調優工具:SQL MonitorOracleSQL
- 效能調優——SQL最佳化SQL
- 如何分析一條sql的效能SQL
- 通過新增條件優化SQL優化SQL
- Oracle 調優確定存在問題的SQLOracleSQL
- 資料庫SQL調優的幾種方式資料庫SQL
- SQL調優13連問,收藏好!SQL
- MySQL 索引和 SQL 調優總結MySql索引
- Oracle SQL調優之分割槽表OracleSQL
- 一條Sql的執行過程SQL
- mysql調優從書寫sql開始MySql
- sql 多組條資料取最新的一條資料SQL
- Oracle 高效能SQL引擎剖析--SQL優化與調優機制詳解OracleSQL優化
- 詳解SQL效能優化十條經驗SQL優化
- 【慢SQL效能最佳化】 一條SQL的生命週期SQL
- 【SQL】SQL中if條件的使用SQL
- 提高mysql千萬級大資料SQL查詢優化30條經驗(Mysql索引優化注意)MySql大資料優化索引
- mybatis原始碼解讀---一條sql的旅程MyBatis原始碼SQL
- MySQL 中一條 sql 的執行過程MySql
- 一條 sql 的執行過程詳解SQL
- 一條sql語句的執行過程SQL
- SQL調優工具包DBMS_SQLTUNE的使用方法SQL
- 如何調優 Oracle SQL系列文章:查詢優化器介紹OracleSQL優化
- PostgreSQL技術大講堂 - 第72講:索引與SQL調優之禁忌之戀SQL索引
- TiDB SQL調優案例之避免TiFlash幫倒忙TiDBSQL
- 一條更新的SQL語句是如何執行的?SQL