同样的代码逻辑，同样的表结构，由于数据量的不同导致查询没有走索引，而引起请求超时案例分析

问题描述：

预发环境目前加载全部变更会超时，线上正常。需要看一下是什么问题避免预发上的问题带到线上

 

 

 

 

 

 

分析解决过程：

EXPLAIN

SELECT i.damand_manager_info_id as damand_manager_id,

title,

i.damand_change_type,

i.customer_cloud_name_id,

i.damand_change_type_l2,

i.gmt_create,

i.pre_begin_time,

i.change_status,

i.category,

i.damand_pri,

i.change_result,

i.pre_end_time,

i.executor,

i.creator,

i.pro_inst_id,

i.damand_id,

i.share_change,

i.creator,

i.change_resaon,

i.actual_begin_time,

i.actual_end_time,

i.cloud_product,

i.cloud_site_id as site_id,

s.aliase,

s.cloud_site_name as site_name,

i.template_id,

i.is_curing,

i.risk_level,

i.sky_eye_id,

(CASE WHEN idbf.damand_id IS NULL THEN 0 WHEN idbf.`is_valid`= 0 THEN 0 ELSE 1 END) AS hasTodo,

(CASE WHEN idbf.`is_valid`= 0 THEN 0 WHEN idbf.status IS NULL THEN 0 WHEN idbf.status= '已处理' THEN 0 WHEN idbf.status= '未处理' THEN 1 ELSE 0 END) AS todoStatus

from damand_manager_info i

LEFT JOIN damand_manager_info_son son ON i.damand_manager_info_id= son.damand_manager_id

LEFT JOIN cloud_site s ON i.cloud_site_id= s.id

LEFT JOIN itom_damand_backfills idbf on idbf.damand_id= i.`damand_manager_info_id`

order by i.gmt_create desc

limit 0,

10;查看这个sql语句的执行计划，发现预发和生产不一样

预发：

生产：

解决方法：是更改sql语句，让它强制走索引，格式如下：force index("索引名")；

加上force index(idx_201903081253)和force index(idx_damand_id);如下：

 explain SELECT

    i.damand_manager_info_id AS damand_manager_id,

    title,

    i.damand_change_type,

    i.customer_cloud_name_id,

    i.damand_change_type_l2,

    i.gmt_create,

    i.pre_begin_time,

    i.change_status,

    i.category,

    i.damand_pri,

    i.change_result,

    i.pre_end_time,

    i.executor,

    i.creator,

    i.pro_inst_id,

    i.damand_id,

    i.share_change,

    i.creator,

    i.change_resaon,

    i.actual_begin_time,

    i.actual_end_time,

    i.cloud_product,

    i.cloud_site_id AS site_id,

    s.aliase,

    s.cloud_site_name AS site_name,

    i.template_id,

    i.is_curing,

    i.risk_level,

    i.sky_eye_id,(

    CASE

    

    WHEN idbf.damand_id IS NULL THEN

    0 

    WHEN idbf.`is_valid` = 0 THEN

    0 ELSE 1 

    END 

    ) AS hasTodo,(

    CASE

    

    WHEN idbf.`is_valid` = 0 THEN

    0 

    WHEN idbf.STATUS IS NULL THEN

    0 

    WHEN idbf.STATUS = '已处理' THEN

    0 

    WHEN idbf.STATUS = '未处理' THEN

    1 ELSE 0 

    END 

    ) AS todoStatus 

    FROM

    damand_manager_info i  force index(idx_201903081253)

    LEFT JOIN damand_manager_info_son son ON i.damand_manager_info_id = son.damand_manager_id

    LEFT JOIN cloud_site s ON i.cloud_site_id = s.id

    LEFT JOIN itom_damand_backfills idbf  force index(idx_damand_id)  ON idbf.damand_id = i.`damand_manager_info_id` 

    ORDER BY

    i.gmt_create DESC 

    LIMIT 0,10

    参考网址见：https://www.cnblogs.com/lipengsheng-javaweb/p/16619073.html

    

    

    

    

标签：damand,同样,manager,cloud,数据量,超时,id,change,idbf
来源： https://www.cnblogs.com/lipengsheng-javaweb/p/16619067.html