Mysql慢sql優化案例之使用force index改變執行計劃

一 問題描述

生產有個這樣的慢sql：

SELECT

   ua.id AS "id",

   ua.appid AS "appid",

   ua.user_id AS "userId",

   ua.create_time AS "createTime",

   ua.deptid AS "deptid",

   ua.group_id AS "groupId",

   ua.sort AS "sort",

   ac.app_name AS "appName",

   ac.app_range AS "appRange",

   ac.app_icon AS "appIcon",

   ac.app_short_name AS "appShortName",

   ac.app_path AS "appPath",

   ac.user_count AS "userCount"

  FROM td_unicom_user_app ua #force index(IDX_USER_APP_DEPTID)

  LEFT JOIN

   td_unicom_app_config ac

  ON

   ua.appid = ac.appid

   WHERE ac.app_status='1'

   AND ac.app_publish_status = '1'  

    AND ua.user_id != 'he-wangdm6'

  

    AND ua.deptid IN

    (

     '00'

    ,

     '0000'

    ,

     '0013'

    ,

     '001302'

    ,

     '00130254227'

    )

  

  

   ORDER BY ua.deptid DESC

查詢執行需要14秒，返回8千多條數據。

執行計劃如下：

查看ua表的索引：

ua表在deptid上有個索引，這裏卻沒使用該索引，奇怪。

二 解決辦法

 

這裏結合實際情況選擇force index這種方式(強制走ua的索引IDX_USER_APP_DEPTID)：

SELECT

   ua.id AS "id",

   ua.appid AS "appid",

   ua.user_id AS "userId",

   ua.create_time AS "createTime",

   ua.deptid AS "deptid",

   ua.group_id AS "groupId",

   ua.sort AS "sort",

   ac.app_name AS "appName",

   ac.app_range AS "appRange",

   ac.app_icon AS "appIcon",

   ac.app_short_name AS "appShortName",

   ac.app_path AS "appPath",

   ac.user_count AS "userCount"

  FROM td_unicom_user_app ua FORCE INDEX(IDX_USER_APP_DEPTID)

  LEFT JOIN

   td_unicom_app_config ac

  ON

   ua.appid = ac.appid

   WHERE ac.app_status='1'

   AND ac.app_publish_status = '1'  

    AND ua.user_id != 'he-wangdm6'

    AND ua.deptid IN

    (

     '00'

    ,

     '0000'

    ,

     '0013'

    ,

     '001302'

    ,

     '00130254227'

    )

   ORDER BY ua.deptid DESC

查詢從14秒降爲了0.05秒。

執行計劃：