<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精品免费视频| 另类小说亚洲色图| 国产一区二区免费视频| 国产亚洲精品不卡在线| 国产亚洲精品无码专区| 免费手机在线看片| 国产亚洲?V无码?V男人的天堂 | 日本19禁啪啪无遮挡免费动图| 久久综合亚洲色HEZYO社区 | 午夜视频在线观看免费完整版| 亚洲欧洲国产综合AV无码久久| 女人毛片a级大学毛片免费| 亚洲AV日韩AV永久无码色欲| 五月婷婷亚洲综合| 99久久免费国产特黄| 亚洲免费在线播放| 国产一卡2卡3卡4卡2021免费观看 国产一卡2卡3卡4卡无卡免费视频 | 国产成人亚洲综合在线| 亚洲日本韩国在线| 久久福利青草精品资源站免费| 亚洲狠狠狠一区二区三区| 国产精品久久久久久久久久免费 | 亚洲人成欧美中文字幕| 免费人成年激情视频在线观看 | 巨胸狂喷奶水视频www网站免费| 亚洲va无码手机在线电影| 色影音免费色资源| 色天使色婷婷在线影院亚洲| 亚洲精品无码久久久久去q | 中文字幕乱理片免费完整的| 亚洲精品午夜视频| 免费一级特黄特色大片在线观看 | 日韩视频在线观看免费| 亚洲国产成人99精品激情在线| 亚洲乱码中文字幕手机在线| 亚在线观看免费视频入口| 亚洲精品无码久久久久久| 亚洲va无码专区国产乱码| 国产精品色午夜视频免费看| 人人揉揉香蕉大免费不卡| 亚洲av永久无码精品秋霞电影秋|