亚洲中字慕日产2020,大陆极品少妇内射AAAAAA,无码av大香线蕉伊人久久,久久精品国产亚洲av麻豆网站

資訊專欄INFORMATION COLUMN

性能優(yōu)化之日期字段索引引發(fā)的血案一例

IT那活兒 / 2328人閱讀
性能優(yōu)化之日期字段索引引發(fā)的血案一例


前面看IT那活兒上不少兄弟都發(fā)表了文章，作為新四有好青年，咱也來湊湊熱鬧，畢竟會下蛋的雞（總結(jié)提煉輸出），才不是肉食雞，才是飛機中的殲21。今天和大家來分享一個日期字段索引引發(fā)的血案及分析過程。

先給出今天的主角SQL語句：

咱先來掐指一算，分析下SQL語句的結(jié)構(gòu)。此語句一打眼就是個統(tǒng)計語句，查詢包括兩張表，是一個正常的表等值關(guān)聯(lián)的查詢語句。


走過路過，但別錯過的看看這個執(zhí)行計劃是否最優(yōu)？

通過仔細查看發(fā)現(xiàn)如上執(zhí)行計劃是錯誤的。簡單啰嗦一下執(zhí)行計劃。首先通過T1表的DATE字段選擇過濾出結(jié)果集，在將表T通過CUSTMGR字段選擇出結(jié)果集，再將兩個查詢的結(jié)果集通過NESTLOOP方式返回數(shù)據(jù)。正常情況下如果連接條件不是通過函數(shù)進行轉(zhuǎn)換且CUST_ID上有索引的話，會通過索引CUST_ID進行NESTLOOP 返回結(jié)果。

那么我們怎么知道選擇這種執(zhí)行計劃時不正確的呢？因為比之前正確的執(zhí)行計劃消耗更高。什么？我怎么知道的消耗更高？往下看就知道了嘛。


通過歷史視圖查詢對應(yīng)SQL_ID執(zhí)行歷史：

通過上面的查詢結(jié)果，我們可以發(fā)現(xiàn)在3:30 ，出現(xiàn)了錯誤的執(zhí)行計劃。那么問題就來了，為什么會有錯誤的執(zhí)行計劃，為什么在10號發(fā)生？

我們可以推斷此SQL是在每天3:30的時候進行定時執(zhí)行，且10號前執(zhí)行效率很高，所有2500次的執(zhí)行均在秒內(nèi)時間就完成了。但在10號后，由于錯誤執(zhí)行計劃出現(xiàn)，導(dǎo)致SQL執(zhí)行時間變長，2500次的執(zhí)行不能在規(guī)定時間內(nèi)跑完，導(dǎo)致sql取數(shù)拖到了半天，占用白天的資源，進而影響正常的白天業(yè)務(wù)。

那么為什么會發(fā)生這樣的情況呢？我們通過10053來仔細在查看一下：


錯誤執(zhí)行計劃的10053trace：

可以看到提示：Usingprorated density: 0.000001 of col #9 as selectvity ofout-of-range/non-existent value pred

這個提示說明出現(xiàn)了越界現(xiàn)象。當(dāng)日期判斷的范圍超出了統(tǒng)計信息記錄的最大值和最小值的范圍，CBO無法計算選擇率，得出錯誤的結(jié)果集，此時通過估計值進行選擇，當(dāng)評估的值與實際情況差別很大時，就會出現(xiàn)選擇偏差。


查看表上日期字段的統(tǒng)計值

我們看到記錄的最大日志是07-10，在與SQL語句SERVICEDATE>= (SYSDATE -30)執(zhí)行計劃出錯的日期進行比較，發(fā)現(xiàn)8月10號-30天正好超過了記錄的最大日期值。這就是執(zhí)行計劃變化發(fā)生在8月10日的罪魁禍首。


現(xiàn)在咱改寫一下SQL語句，再看一下執(zhí)行計劃

執(zhí)行計劃已正確。


看一下對應(yīng)的10053trace信息
很明顯與之前錯誤執(zhí)行計劃trace信息不同，得到的COST和結(jié)果集大小不同。

我們通過上面的分析知道了問題出現(xiàn)的原因，處理方法也很簡單：

  • 1. 收集表上統(tǒng)計信息

  • 2. 固定SQL的執(zhí)行計劃

  • 3. 創(chuàng)建組合索引，CUSTMGR+時間

  • 3.2 監(jiān)控執(zhí)行計劃的變化

數(shù)據(jù)是千變?nèi)f化的，作為一個老司機，我們多伸一下手順帶考慮通過編寫監(jiān)控腳本來預(yù)防問題的后續(xù)發(fā)生，發(fā)生時第一時間知曉及介入。


腳本的實現(xiàn)思路：

  • 1. 監(jiān)控系統(tǒng)中出現(xiàn)SQL_ID和PLAN_HASH_VALUE,1：N的情況，過濾掉OBJECT_STATUS失效的對象，正常一個SQL_ID與一個當(dāng)前真正使用的PLAN_HASH_VALUE對應(yīng)，比較執(zhí)行時間進行報警。

  • 2. 比較SQL_ID-PLAN_HASH_VALUE在歷史中是否出現(xiàn)過，比較執(zhí)行時間進行報警。

  • 3. 使用SQL審核平臺進行監(jiān)控告警。

好了，本新四有好青年的首次春宮秀到此結(jié)束，咱們下回再見。

文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/130212.html

相關(guān)文章

  • 空數(shù)組返回true引發(fā)的血案

    摘要：但是在這個判斷的情況下，則會很神奇的發(fā)現(xiàn)打印出來了，說明此時為，為什么呢因為這里執(zhí)行了一個對象到布爾值的轉(zhuǎn)換故返回。 ????之前做項目的時候，總會處理各式各樣的數(shù)據(jù)，來進行繪圖。但是當(dāng)后臺返回一個空數(shù)組的時候，頁面中并不會顯示沒有數(shù)據(jù)的圖。代碼如下： var arr = [] if(arr){console.log(124)}else{console.log(無數(shù)據(jù))} 我明明判斷了...

    piglei 評論0 收藏0

  • 在PHP應(yīng)用程序開發(fā)中不正當(dāng)使用mail()函數(shù)引發(fā)的血案

    摘要：在我們向廠商提交漏洞，發(fā)布了相關(guān)的漏洞分析文章后，由于內(nèi)聯(lián)函數(shù)導(dǎo)致的類似安全問題在其他的應(yīng)用程序中陸續(xù)曝出。淺析的函數(shù)自帶了一個內(nèi)聯(lián)函數(shù)用于在應(yīng)用程序中發(fā)送電子郵件。 前言 在我們 挖掘PHP應(yīng)用程序漏洞 的過程中，我們向著名的Webmail服務(wù)提供商 Roundcube 提交了一個遠程命令執(zhí)行漏洞（ CVE-2016-9920 ）。該漏洞允許攻擊者通過利用Roundcube接口發(fā)送一...

    Galence 評論0 收藏0

  • 增量部署class文件引發(fā)的血案

    摘要：背景項目中通過遠程調(diào)用服務(wù)框架調(diào)用了許多其它的服務(wù)其中有一個服務(wù)需要升級其升級不是版本上的升級而是整個服務(wù)重新取了一個名字使用的也是全新的包但是調(diào)用的方法沒有改變因此在升級時只是在調(diào)用服務(wù)類中修改了調(diào)用地址和調(diào)用返回實體由改為該中返回該調(diào)用 背景 項目中通過遠程調(diào)用服務(wù)框架調(diào)用了許多其它的服務(wù),其中有一個服務(wù)wx/subscribe/contract/CircleService 需要升...

    lolomaco 評論0 收藏0

  • 記一次Content-Length引發(fā)的血案

    摘要：除非使用了分塊編碼，否則首部就是帶有實體主體的報文必須使用的。 背景 新項目上線, 發(fā)現(xiàn)一個奇怪的BUG, 請求接口有很小的概率返回400 Bad Request,拿到日志記錄的請求的參數(shù)于POSTMAN中測試請求接口, 發(fā)現(xiàn)能夠正常響應(yīng). 排查過程 首先服務(wù)器能夠正常響應(yīng)400 Bad Request, 排除接口故障問題. 對比日志過程中發(fā)現(xiàn) { hello:world ...

    thekingisalwaysluc 評論0 收藏0

發(fā)表評論

0條評論

IT那活兒

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<