一. 表介绍

1）本次车辆场景使用了2张表 vehicle以及vehicle_extra，两张表皆为按天进行分区的分区表。

2）两表通过info_id关联，info_id为唯一值可作为主键使用。针对同一个info_id, capture_time (抓拍时间) 一定在vehicle与vehile_extra表中是相同的。

3） capture_time以时间撮形式记录在表中。

二. 使用列存表

车辆检索与技战法的语句中包含关联查询，区间范围选择，点查询等等场景，在实际测试中发现使用列存表的性能会稍强于行存表。

三. 车辆检索

自定义特征值搜车与以图搜车在业务上较为相似，区别是自定义特征搜车会圈出几个图片中的特殊地方与数据库中的记录比对。这里我们就以以图搜车为例进行介绍。以下语句通过前端搜索图片，后台获取。

select v.info_id,ve.feature,v.brand_id

from vehicle v

left join vehicle_extra ve

on v.info_id=ve.info_id

where (brand_id in (130)

and (v.capture_time >=1592755200 and v.capture_time <= 1592841355 )

and (license_plate1 <> ‘鲁B123456’ or license_plate2 <> ‘鲁B123456’) and source_id in(22,23))

and feature is not null and feature <> ‘\x’

order by v.capture_time desc limit 24;

PS: capture_time >=1592755200 and v.capture_time <= 1592841355 对应的时间范围是2020-06-22 00:00:00 - 2020-06-22 23:55:55。

对于这个业务场景我做了2个地方的优化。

1）开启SMP

set query_dop=10

2）根据业务逻辑修改语句如下

select v.info_id,ve.feature,v.brand_id

from vehicle v

left join vehicle_extra ve

on v.info_id=ve.info_id

where (brand_id in (130)

and (v.capture_time >=1592755200 and v.capture_time <= 1592841355 )

and (ve.capture_time >=1592755200 and ve.capture_time <= 1592841355 )

and (license_plate1 <> ‘鲁B123456’ or license_plate2 <> ‘鲁B123456’) and source_id in(22,23))

and feature is not null and feature <> ‘\x’

order by v.capture_time desc limit 24;

在以上场景中查询的是2020-6-22这天符合条件的车辆，原语句中限定了vehicle表的时间范围，却对vehicle_extra进行全表扫描。根据第一部分表部分业务字段的解析，这里我们可以举个简单的例子。在vehicle表中我们查询到的2020-6-22日期里的某辆车的抓拍记录，所能关联到的vehicle_extra表记录绝对不会出现在vehicle_extra中2020-6-22日期以外的区间里。

因此，修改原语句增加clause条件and (ve.capture_time >=1592755200 and ve.capture_time <= 1592841355 ) 可以将全表扫描改成分区扫描，大幅度降低扫描的数据量从而提升性能。

以下是修改语句的性能提升结果。