码迷,mamicode.com
首页 > 数据库 > 详细

一些关于SQL优化的总结

时间:2018-09-01 18:05:23      阅读:185      评论:0      收藏:0      [点我收藏+]

标签:modify   comm   inf   pem   sel   包含   inter   count   _id   

慢SQL核查

NO.1 :com.cmos.dao.basesr.TSrProblemProcesExceptionMapper.queryExceptionCount

SELECT

    count(1)

FROM

    t_sr_problem_proces t1,

    (

       SELECT

           WRKFM_ID

       FROM

           t_sr_problem_process_modify

       GROUP BY

           WRKFM_ID

    ) t2

WHERE

    t1.ACPT_TIME >= ‘2018-07-31 00:00:00‘

AND t1.ACPT_TIME <= ‘2018-08-31 23:59:59‘

AND t1.TENANT_ID = ‘100000‘

AND t1.PROV_CODE = ‘00030016‘

AND t1.WRKFM_ID = t2.WRKFM_ID

AND t1.WRKFM_STS_CD IN (‘3‘, ‘4‘, ‘5‘, ‘7‘, ‘8‘);

 

分析:

子查询的结果集t2在与t1表联合时会走全表扫描,且没有索引。

改造:

SELECT

    count(distinct t1.WRKFM_ID)

FROM

    t_sr_problem_proces t1,

    t_sr_problem_process_modify t2

WHERE

    t1.ACPT_TIME >= ‘2018-07-31 00:00:00‘

AND t1.ACPT_TIME <= ‘2018-08-31 23:59:59‘

AND t1.TENANT_ID = ‘100000‘

AND t1.PROV_CODE = ‘00030016‘

AND t1.WRKFM_ID = t2.WRKFM_ID

AND t1.WRKFM_STS_CD IN (‘3‘, ‘4‘, ‘5‘, ‘7‘, ‘8‘);

 

改造后的SQL两条执行计划均走索引查询

NO.2  com.cmos.dao.basesr.TSrProblemProcesExceptionMapper.queryExceptionCount_His

SELECT

 count(1)

FROM

 t_sr_problem_proces_h_2018 t1,

 (

  SELECT

   WRKFM_ID

  FROM

   t_sr_problem_process_modify_his_2018

  GROUP BY

   WRKFM_ID

 ) t2

WHERE

 t1.ACPT_TIME >= ?

AND t1.ACPT_TIME <= ?

AND t1.TENANT_ID = ?

AND t1.PROV_CODE = ?

AND t1.WRKFM_ID = t2.WRKFM_ID

 

分析:

子查询的结果集t2在与t1表联合时会走全表扫描,且没有索引。

NO.3   com.cmos.service.commonsv.generator.TSrCfgHotSrtypeMapper.selectByCond

 

SELECT

    REC_ID,

    TENANT_ID,

    PROV_CODE,

    SRV_REQST_TYPE_ID,

    CITY_CODE,

    SRV_REQST_BIG_CLA_ID,

     HTPOINT_SRV_REQST_TYPE_NM,

    HTPOINT_SRV_REQST_TYPE_FULL_NM,

    OP_STAFF_ID,

    ARGE_SEQNO,

    ORG_BRNCH_ID,

    CRT_TIME,

    MODF_TIME,

    HTPOINT_SRV_TYPE_CD,

    BATCH_NUM,

    VALID_FLAG,

    ACPT_FLAG,

    BIG_CLA_NM,

    LTSZ_WRKFM_FLAG,

    EFF_TIME,

    INVLD_TIME,

    FRONT_SHOW_NM

FROM

    t_sr_cfg_hot_srtype

ORDER BY

    ?

LIMIT ?,?

 

 

分析:

手动热点服务请求类型查询:

1.该SQL是简单的单标查询,经过排查该xml中的sql语句可以删除

distinct

2.该sql查询的字段可以看出,包含主键,因此distinct 将毫无意义,如果误传的话还会降低该查询的性能

该查询是简单的单表查询,经核查 t_sr_cfg_hot_srtype 在配置库,所有省份共用一张表,该表主键是REC_ID,在查询是REC_ID不会由前台传过来,因此where 子句中不会有 REC_ID 导致查询不会走索引查

改造: 建议对于该表新增其他列的索引

NO.4 com.cmos.service.commonsv.generator.TSrCfgHotSrtypeRuleMapper.selectByCond

 

SELECT

    RULE_ID,

    TENANT_ID,

    PROV_CODE,

    HTPOINT_SRV_TYPE_CD,

    EMBR_CITY_FLAG,

    EMBR_BIG_CLA_FLAG,

    INTERVALG,

    TOPN,

    OP_STAFF_ID,

    ORG_BRNCH_ID,

    CRT_TIME,

    MODF_TIME

FROM

    t_sr_cfg_hot_srtype_rule

WHERE

    ?

ORDER BY

    ?

 

分析:

1.该SQL是简单的单标查询,经过排查该xml中的sql语句可以删除distinct

该sql查询的字段可以看出,包含主键,因此distinct 将毫无意义,如果误传的话还会降低该查询的性能

2.该表位于配置库,多省共用一张表存储数据,经查询该表仅有主键一个索引,在查询时不会传主键到where 子句中,因此导致该简单查询为全表扫描且不走索引,无论哪个省的数据量足够大都会影响其他省的正常查询。

改进:建议该表新增索引

NO.5 com.cmos.dao.basesr.TSrProcessDetailHisMapper.selectByRouteLgIds

 

SELECT

    DSPS_PROC_ID,

    TENANT_ID,

    LG_ID,

    ROUTE_LG_ID,

    WRKFM_ID,

    OP_TYPE_CD,

    FCT_NO,

    FCT_NM,

    FCT_VAL,

    DSPS_STAFF_ID,

    DSPS_ORG_BRNCH_ID,

    CRT_TIME,

    MODF_TIME,

    PROV_CODE,

    ELEMENT_DISPLAY_NAME

FROM

    t_sr_process_detail_his_201808

WHERE

    ROUTE_LG_ID IN (?,?,?)

 

 

分析:

 

1.排查xml的时候,发现#{id} 没有添加jdbcType

2.以 t_sr_process_detail_his_201808 为例,该表中除主键外 还有在WRKFM_ID上有索引,但是针对该SQL WRKFM_ID 不在where子句中,因此查询为全表扫面且不走索引

改进:在 ROUTE_LG_ID 字段上添加索引

NO.6 SrPageInfo.selectCfgPageType

 

SELECT DISTINCT

    (APP_CLFC_CD)

FROM

    t_sr_page_info

WHERE

    TENANT_ID = ?

AND PROV_CODE = ?

 

分析:

 

t_sr_page_info位于配置库,主键:PAGE_ID 除主键外无其他索引

该查询虽然是简单查询,但是在数据量很大的时候,全表扫面会效率极低。

改进:在PROV_CODE 字段上新增索引

 

查询表中索引:

show index from table_name

一些关于SQL优化的总结

标签:modify   comm   inf   pem   sel   包含   inter   count   _id   

原文地址:https://www.cnblogs.com/zhaiyt/p/9571014.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!