一些关于SQL优化的总结
Posted zhaiyt
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了一些关于SQL优化的总结相关的知识,希望对你有一定的参考价值。
慢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优化的总结的主要内容,如果未能解决你的问题,请参考以下文章
SQL数据库数据优化SQL优化总结( 百万级数据库优化方案)