记一次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比之前快了约一百七十多倍：

看下执行计划：