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

问题描述:

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

 

 

 

 

 

 

分析解决过程:

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

    

    

    

    

posted on   芝麻开花——节节高  阅读(41)  评论(0编辑  收藏  举报

相关博文:
阅读排行:
· winform 绘制太阳,地球,月球 运作规律
· 震惊!C++程序真的从main开始吗?99%的程序员都答错了
· AI与.NET技术实操系列(五):向量存储与相似性搜索在 .NET 中的实现
· 【硬核科普】Trae如何「偷看」你的代码?零基础破解AI编程运行原理
· 超详细:普通电脑也行Windows部署deepseek R1训练数据并当服务器共享给他人

导航

< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5
点击右上角即可分享
微信分享提示