表A：批次信息表，
表B：实际批次明细表，
Mysql版本：5.6.36
两表之间的数据体量差异：表B是表A的10000倍。
经过结转，表B通常保留 1千5百万数据。表A就是1千多条数据。
计算近24小时时段，24个批次中最大的一批。由于指标量是每天随时间推移而变大，因此需要取每个小时最后一批，即是该时段最终指标。减去上一小时指标量即为当前时段内的指标考核量。
原SQL逻辑是 先用两个表A左连接，连接时将批次时间的Hour + 1使批次正好错一个小时。得到当前时段与上一时段的批次。
再与表B关联，得到两个24批的实际明细，此处将大表表B,关联了两次，前面描述，表B数据量在1500万。导致最终查询时间在50S左右。
修改后的方式：
使用子查询，先找出第一个24小时时段的明细数据，大概在3万左右数据。再用第二个子查询找出时段错1个小时的25批明细数据。最后将两个子查询使用 hour + 1的方式进行left join。由于子查询提前过滤了数据量，最终查询相应时间缩短至 700ms左右。超出预期。达到优化目的。
当然，此处不是即席查询应用，而是离线worker,700ms 相比较于 50S提升当然是非常可观的，对于支持实时相应的查询，200ms以上的可能都要考虑其他方式进行优化了。
由于涉及数据保密，此处不对具体分析过程进行拆解，仅是思路。在大表关联时尽可能提前缩小数据扫描范围，有时候子查询并不一定总是降低效率，这点在HIVE-SQL中体现尤为明显。