国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

性能優化之日期字段索引引發的血案一例

IT那活兒 / 2291人閱讀
性能優化之日期字段索引引發的血案一例


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

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

咱先來掐指一算,分析下SQL語句的結構。此語句一打眼就是個統計語句,查詢包括兩張表,是一個正常的表等值關聯的查詢語句。


走過路過,但別錯過的看看這個執行計劃是否最優?

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

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


通過歷史視圖查詢對應SQL_ID執行歷史:

通過上面的查詢結果,我們可以發現在3:30 ,出現了錯誤的執行計劃。那么問題就來了,為什么會有錯誤的執行計劃,為什么在10號發生?

我們可以推斷此SQL是在每天3:30的時候進行定時執行,且10號前執行效率很高,所有2500次的執行均在秒內時間就完成了。但在10號后,由于錯誤執行計劃出現,導致SQL執行時間變長,2500次的執行不能在規定時間內跑完,導致sql取數拖到了半天,占用白天的資源,進而影響正常的白天業務。

那么為什么會發生這樣的情況呢?我們通過10053來仔細在查看一下:


錯誤執行計劃的10053trace:

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

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


查看表上日期字段的統計值

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


現在咱改寫一下SQL語句,再看一下執行計劃

執行計劃已正確。


看一下對應的10053trace信息
很明顯與之前錯誤執行計劃trace信息不同,得到的COST和結果集大小不同。

我們通過上面的分析知道了問題出現的原因,處理方法也很簡單:
  • 1. 收集表上統計信息

  • 2. 固定SQL的執行計劃

  • 3. 創建組合索引,CUSTMGR+時間

  • 3.2 監控執行計劃的變化

數據是千變萬化的,作為一個老司機,我們多伸一下手順帶考慮通過編寫監控腳本來預防問題的后續發生,發生時第一時間知曉及介入。


腳本的實現思路:
  • 1. 監控系統中出現SQL_ID和PLAN_HASH_VALUE,1:N的情況,過濾掉OBJECT_STATUS失效的對象,正常一個SQL_ID與一個當前真正使用的PLAN_HASH_VALUE對應,比較執行時間進行報警。

  • 2. 比較SQL_ID-PLAN_HASH_VALUE在歷史中是否出現過,比較執行時間進行報警。

  • 3. 使用SQL審核平臺進行監控告警。

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

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/130212.html

相關文章

  • 空數組返回true引發血案

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

    piglei 評論0 收藏0
  • 在PHP應用程序開發中不正當使用mail()函數引發血案

    摘要:在我們向廠商提交漏洞,發布了相關的漏洞分析文章后,由于內聯函數導致的類似安全問題在其他的應用程序中陸續曝出。淺析的函數自帶了一個內聯函數用于在應用程序中發送電子郵件。 前言 在我們 挖掘PHP應用程序漏洞 的過程中,我們向著名的Webmail服務提供商 Roundcube 提交了一個遠程命令執行漏洞( CVE-2016-9920 )。該漏洞允許攻擊者通過利用Roundcube接口發送一...

    Galence 評論0 收藏0
  • 增量部署class文件引發血案

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

    lolomaco 評論0 收藏0
  • 記一次Content-Length引發血案

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

    thekingisalwaysluc 評論0 收藏0

發表評論

0條評論

IT那活兒

|高級講師

TA的文章

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