记一次MySQL索引优化
两张表是主(CHECK_DRAWINGS)从(CHECK_DRAWINGS_IMG)关系。
CHECK_DRAWINGS,主表数据 3591条。
SELECT COUNT(*) FROM CHECK_DRAWINGS; -- 3591
CHECK_DRAWINGS_IMG,从表数据107203条,数据量并不大,从表通过check_drawings_id关联主表的主键id。
SELECT COUNT(*) FROM CHECK_DRAWINGS_IMG; -- 107203
现有一条SQ如下,根据exhibition_id查询出主表下最后上传的数据
SELECT cdi.*, cd.booth_id FROM check_drawings_img cdi, check_drawings cd WHERE cdi.check_drawings_id = cd.id AND cd.exhibition_id = 'c480ffc7aed24789b025397c5b66ce88' AND cdi.upload_time = (SELECT MAX(cdi2.upload_time) FROM check_drawings_img cdi2 WHERE cdi2.check_drawings_id = cd.id) ;
执行时间达到了14s左右,显然是无法接收的。
通过mysql explain 执行计划信息如下:
id
SELECT识别符,这是SELECT查询序列号。
select_type
simple 它表示简单的select,没有union和子查询
primary 最外面的select,在有子查询的语句中,最外面的select查询就是primary
dependent_subquery 看到 SQL 执行计划中 select_type 字段中出现“DEPENDENT SUBQUERY”时,需要特别注意了。
type
all : 即全表扫描
index : 按索引次序扫描,先读索引,再读实际的行,结果还是全表扫描,主要优点是避免了排序。因为索引是排好的。
range:以范围的形式扫描。
ref:非唯一索引访问(只有普通索引)
eq_ref:使用唯一索引查找(主键或唯一索引)
const:常量查询
解决方式一增加索引:
1、增加索引,我们对外检check_drawings_img.check_drawings_id增加索引如下:
ALTER TABLE check_drawings_img ADD INDEX check_drawings_id_idx (check_drawings_id) ;
再次执行,0.078s比之前快了约一百七十多倍:
看下执行计划: