<span id="mktg5"></span>

<i id="mktg5"><meter id="mktg5"></meter></i>

        <label id="mktg5"><meter id="mktg5"></meter></label>
        最新文章專題視頻專題問答1問答10問答100問答1000問答2000關鍵字專題1關鍵字專題50關鍵字專題500關鍵字專題1500TAG最新視頻文章推薦1 推薦3 推薦5 推薦7 推薦9 推薦11 推薦13 推薦15 推薦17 推薦19 推薦21 推薦23 推薦25 推薦27 推薦29 推薦31 推薦33 推薦35 推薦37視頻文章20視頻文章30視頻文章40視頻文章50視頻文章60 視頻文章70視頻文章80視頻文章90視頻文章100視頻文章120視頻文章140 視頻2關鍵字專題關鍵字專題tag2tag3文章專題文章專題2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章專題3
        問答文章1 問答文章501 問答文章1001 問答文章1501 問答文章2001 問答文章2501 問答文章3001 問答文章3501 問答文章4001 問答文章4501 問答文章5001 問答文章5501 問答文章6001 問答文章6501 問答文章7001 問答文章7501 問答文章8001 問答文章8501 問答文章9001 問答文章9501
        當前位置: 首頁 - 科技 - 知識百科 - 正文

        淺談MySQL中的子查詢優化技巧

        來源:懂視網 責編:小采 時間:2020-11-09 21:01:06
        文檔

        淺談MySQL中的子查詢優化技巧

        淺談MySQL中的子查詢優化技巧:mysql的子查詢的優化一直不是很友好,一直有受業界批評比較多,也是我在sql優化中遇到過最多的問題之一,你可以點擊這里 ,這里來獲得一些信息,mysql在處理子查詢的時候,會將子查詢改寫,通常情況下,我們希望由內到外,也就是先完成子查詢的結果,然后在用子
        推薦度:
        導讀淺談MySQL中的子查詢優化技巧:mysql的子查詢的優化一直不是很友好,一直有受業界批評比較多,也是我在sql優化中遇到過最多的問題之一,你可以點擊這里 ,這里來獲得一些信息,mysql在處理子查詢的時候,會將子查詢改寫,通常情況下,我們希望由內到外,也就是先完成子查詢的結果,然后在用子

        mysql的子查詢的優化一直不是很友好,一直有受業界批評比較多,也是我在sql優化中遇到過最多的問題之一,你可以點擊這里 ,這里來獲得一些信息,mysql在處理子查詢的時候,會將子查詢改寫,通常情況下,我們希望由內到外,也就是先完成子查詢的結果,然后在用子查詢來驅動外查詢的表,完成查詢,但是恰恰相反,子查詢不會先被執行;今天希望通過介紹一些實際的案例來加深對mysql子查詢的理解:

        案例:用戶反饋數據庫響應較慢,許多業務動更新被卡?。坏卿浀綌祿熘杏^察,發現長時間執行的sql;

        | 10437 | usr0321t9m9 | 10.242.232.50:51201 | oms | Execute | 1179 | Sending
        
        

        Sql為:

        select tradedto0_.* from a1 tradedto0_ where tradedto0_.tradestatus='1'
        and (tradedto0_.tradeoid in (select orderdto1_.tradeoid from a2 orderdto1_ where
        orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%')) and tradedto0_.undefine4='1'
        and tradedto0_.invoicetype='1' and tradedto0_.tradestep='0' and (tradedto0_.orderCompany like '0002%') order by tradedto0_.tradesign ASC, tradedto0_.makertime desc limit 15;
        

        2.其他表的更新被阻塞:

        update a1 set tradesign='DAB67634-795C-4EAC-B4A0-78F0D531D62F',
        markColor=' #CD5555', memotime='2012-09- 22', markPerson='??' where tradeoid in ('gy2012092204495100032') ;
        

        為了盡快恢復應用,將其長時間執行的sql kill掉后,應用恢復正常;
        3.分析執行計劃:

        db@3306 :explain select tradedto0_.* from a1 tradedto0_ where tradedto0_.tradestatus='1' and (tradedto0_.tradeoid in (select orderdto1_.tradeoid
        from a2 orderdto1_ where orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%')) and tradedto0_.undefine4='1' and tradedto0_.invoicetype='1' and tradedto0_.tradestep='0' and (tradedto0_.orderCompany like '0002%') order by tradedto0_.tradesign ASC, tradedto0_.makertime desc limit 15;
        +----+--------------------+------------+------+---------------+------+---------+------+-------+-----
        | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
        +----+--------------------+------------+------+---------------+------+---------+------+-------+-----
        | 1 | PRIMARY | tradedto0_ | ALL | NULL | NULL | NULL | NULL | 27454 | Using where; Using filesort |
        | 2 | DEPENDENT SUBQUERY | orderdto1_ | ALL | NULL | NULL | NULL | NULL | 40998 | Using where |
        +----+--------------------+------------+------+---------------+------+---------+------+-------+-----
        

        從執行計劃上,我們開始一步一步地進行優化:
        首先,我們看看執行計劃的第二行,也就是子查詢的那部分,orderdto1_進行了全表的掃描,我們看看能不能添加適當的索引:
        A.使用覆蓋索引:

        db@3306:alter table a2 add index ind_a2(proname,procode,tradeoid);
        ERROR 1071 (42000): Specified key was too long; max key length is 1000 bytes
        

        添加組合索引超過了最大key length限制:
        B.查看該表的字段定義:

         db@3306 :DESC a2 ;
        +---------------------+---------------+------+-----+---------+-------+
        | FIELD | TYPE | NULL | KEY | DEFAULT | Extra |
        +---------------------+---------------+------+-----+---------+-------+
        | OID | VARCHAR(50) | NO | PRI | NULL | |
        | TRADEOID | VARCHAR(50) | YES | | NULL | |
        | PROCODE | VARCHAR(50) | YES | | NULL | |
        | PRONAME | VARCHAR(1000) | YES | | NULL | |
        | SPCTNCODE | VARCHAR(200) | YES | | NULL | |
        
        

        C.查看表字段的平均長度:

        db@3306 :SELECT MAX(LENGTH(PRONAME)),avg(LENGTH(PRONAME)) FROM a2;
        +----------------------+----------------------+
        | MAX(LENGTH(PRONAME)) | avg(LENGTH(PRONAME)) |
        +----------------------+----------------------+
        | 95 | 24.5588 |
        
        

        D.縮小字段長度

        ALTER TABLE MODIFY COLUMN PRONAME VARCHAR(156);
        
        

        再進行執行計劃分析:

        db@3306 :explain select tradedto0_.* from a1 tradedto0_ where tradedto0_.tradestatus='1' and (tradedto0_.tradeoid in (select orderdto1_.tradeoid from a2 orderdto1_ where orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%')) and tradedto0_.undefine4='1' and tradedto0_.invoicetype='1' and tradedto0_.tradestep='0' and (tradedto0_.orderCompany like '0002%') order by tradedto0_.tradesign ASC, tradedto0_.makertime desc limit 15;
        +----+--------------------+------------+-------+-----------------+----------------------+---------+
        | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
        +----+--------------------+------------+-------+-----------------+----------------------+---------+
        | 1 | PRIMARY | tradedto0_ | ref | ind_tradestatus | ind_tradestatus | 345 | const,const,const,const | 8962 | Using where; Using filesort |
        | 2 | DEPENDENT SUBQUERY | orderdto1_ | index | NULL | ind_a2 | 777 | NULL | 41005 | Using where; Using index |
        +----+--------------------+------------+-------+-----------------+----------------------+---------+
        

        發現性能還是上不去,關鍵在兩個表掃描的行數并沒有減小(8962*41005),上面添加的索引沒有太大的效果,現在查看t表的執行結果:

        db@3306 :select orderdto1_.tradeoid from t orderdto1_ where orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%';
        Empty set (0.05 sec)
        

        結果集為空,所以需要將t表的結果集做作為驅動表;
        4.通過上面測試驗證,普通的mysql子查詢寫法性能上是很差的,為mysql的子查詢天然的弱點,需要將sql進行改寫為關聯的寫法:

        select tradedto0_.* from a1 tradedto0_ ,(select orderdto1_.tradeoid from a2 orderdto1_ where orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%')t2 where tradedto0_.tradestatus='1' and (tradedto0_.tradeoid=t2.tradeoid ) and tradedto0_.undefine4='1' and tradedto0_.invoicetype='1' and tradedto0_.tradestep='0' and (tradedto0_.orderCompany like '0002%') order by tradedto0_.tradesign ASC, tradedto0_.makertime desc limit 15;
        

        5.查看執行計劃:

        db@3306 :explain select tradedto0_.* from a1 tradedto0_ ,(select orderdto1_.tradeoid from a2 orderdto1_ where orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%')t2 where tradedto0_.tradestatus='1' and (tradedto0_.tradeoid=t2.tradeoid ) and tradedto0_.undefine4='1' and tradedto0_.invoicetype='1' and tradedto0_.tradestep='0' and (tradedto0_.orderCompany like '0002%') order by tradedto0_.tradesign ASC, tradedto0_.makertime desc limit 15;
        +----+-------------+------------+-------+---------------+----------------------+---------+------+
        | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
        +----+-------------+------------+-------+---------------+----------------------+---------+------+
        | 1 | PRIMARY | NULL | NULL | NULL | NULL | NULL | NULL | NULL | Impossible WHERE noticed after reading const tables |
        | 2 | DERIVED | orderdto1_ | index | NULL | ind_a2 | 777 | NULL | 41005 | Using where; Using index |
        +----+-------------+------------+-------+---------------+----------------------+---------+------+
        

        6.執行時間:

        db@3306 :select tradedto0_.* from a1 tradedto0_ ,(select orderdto1_.tradeoid from a2 orderdto1_ where orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%')t2 where tradedto0_.tradestatus='1' and (tradedto0_.tradeoid=t2.tradeoid ) and tradedto0_.undefine4='1' and tradedto0_.invoicetype='1' and tradedto0_.tradestep='0' and (tradedto0_.orderCompany like '0002%') order by tradedto0_.tradesign ASC, tradedto0_.makertime desc limit 15;
        Empty set (0.03 sec)
        
        

        縮短到了毫秒;

        您可能感興趣的文章:

      1. MySQL優化之使用連接(join)代替子查詢
      2. MYSQL子查詢和嵌套查詢優化實例解析
      3. mysql in語句子查詢效率慢的優化技巧示例
      4. mysql優化系列 DELETE子查詢改寫優化
      5. mysql關聯子查詢的一種優化方法分析
      6. Oracle數據庫中基本的查詢優化與子查詢優化講解
      7. MySQL的子查詢及相關優化學習教程
      8. 對MySQL子查詢的簡單改寫優化
      9. MySQL查詢優化:用子查詢代替非主鍵連接查詢實例介紹
      10. 數據庫查詢優化之子查詢優化
      11. 聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com

        文檔

        淺談MySQL中的子查詢優化技巧

        淺談MySQL中的子查詢優化技巧:mysql的子查詢的優化一直不是很友好,一直有受業界批評比較多,也是我在sql優化中遇到過最多的問題之一,你可以點擊這里 ,這里來獲得一些信息,mysql在處理子查詢的時候,會將子查詢改寫,通常情況下,我們希望由內到外,也就是先完成子查詢的結果,然后在用子
        推薦度:
        標簽: 查詢 方法 mysql
        • 熱門焦點

        最新推薦

        猜你喜歡

        熱門推薦

        專題
        Top
        主站蜘蛛池模板: 日本免费网站视频www区| 曰批免费视频播放免费| 亚洲第一视频网站| 亚洲国产精品久久久久婷婷软件| 亚洲xxxx18| 国产日韩久久免费影院| 久久国产精品免费网站| 破了亲妺妺的处免费视频国产| 亚洲一区精品伊人久久伊人| 久久夜色精品国产噜噜噜亚洲AV | 亚洲国产精品无码久久九九大片| 羞羞视频免费网站含羞草| 国产精品99久久免费观看| 亚洲狠狠久久综合一区77777| **一级一级毛片免费观看| 丝袜熟女国偷自产中文字幕亚洲| 亚洲av永久无码精品天堂久久 | 久久久久久亚洲av成人无码国产| 久久99青青精品免费观看| 国产做床爱无遮挡免费视频| 亚洲视频在线观看不卡| eeuss免费天堂影院| 国产美女无遮挡免费网站| 亚洲国产系列一区二区三区| 国产精成人品日日拍夜夜免费| 亚洲日韩乱码久久久久久| 一级毛片免费观看| 亚洲日韩国产二区无码| 国产精品怡红院永久免费| 亚洲精品无码专区在线在线播放| 国内成人精品亚洲日本语音| 中文字幕av无码无卡免费| 99ri精品国产亚洲| 青青青青青青久久久免费观看 | 91老湿机福利免费体验| 亚洲国产精品福利片在线观看| 一个人看的www视频免费在线观看| 日本高清免费不卡在线| 亚洲综合色婷婷在线观看| 最近中文字幕免费mv视频8| 亚洲人成黄网在线观看|