优化前SQL说明：

1. 表A left join 表B,Join条件若干，最终做count返回条数。

2. where 条件中 create_time 总是扫描近一个月数据。单次扫描50万左右

3. 表A中整体数量 140万条，表B总体数据量140万条。

4. 其它若干where条件

5. explain返回结果表A扫描记录数50万左右，primary索引，create_time索引，表B关联 1Row，使用到了表A的主键关联，以及自己表中的外键索引

6. 两张表均为主键自增。

优化思路

1. 缩小扫描行数

2. 经过思考，最终选择了，将create_time扫描缩小至1天（大概4000行），也就是过去一个月开始的那天，然后求最小主键ID（min(id) as start_id ）,再使用该ID作为范围起始ID,使用表A的主键 id >= 该起始ID。这样始终使时间范围扫描的是一天的数据量，这个量最大也就是万级别，不会到10万级以上。

3. 主键扫描，优于二级索引。

优化结果

1. 经测试，单表查询，这么做提升并不明显。

2. 关联查询中，多条件复合使用，这么做从单次查询1S+降低至100ms，有将近10倍的性能提升。

总结

1. 本次优化虽增加了一个子查询，但是整体扫描行数缩减明显， 性能提升明显，这里仅仅是提供一种减少扫描行数的优化思路。其中SQL细节，各个业务都不同，不一一列出。