查询优化主要涉及到两块。
1.订单表数据查询优化
订单数据库是单独出来的，每一条记录记录显示都涉及到用户名称(微信号，昵称，app昵称)，商家名称(商家名称，电话)，设备名称(设备编号，车牌号)等。
按照目前的表设计，订单库和用户库，商家库，设备库都独立，表都是通过主键ID进行关联，订单表存放的是userId，merchantId，deviceId等。这种设计方式带来一个瓶颈，就是订单记录显示的时候要通过ID关联查询显示出用户，商家，设备的信息并展示在前端页面。当初在开发过程中，由于时间比较赶，没有做过多的细节优化，都是通过后台订单微服务通过ID去循环查询去用户，商家以及设备的信息再到前端展示，刚开始还好，毕竟每页只显示10条数据，打开页面过程中3秒左右。后面页面调整到显示20条，结果打开这个页面订单微服务偶尔报超时现象。为了解决超时这个问题，将数据组装放到前端，由前端根据ID再请求具体的用户，商家，设备微服务展示相关信息，虽然解决了微服务超时问题，但是前端每次访问页面出现了大量的ajax请求，对前端性能造成非常大的体验影响。也曾经和业务有沟通过，就是这个订单页面显示的时候能不能不显示用户，商家，设备的信息，只显示订单记录相关，然后通过点订单详情进入详情页面再显示用户，商家，设备信息，但是业务这块产品体验又不太好，所以还是得想办法解决这个问题。其实这块订单表当初设计的时候太过于追求数据库的设计范式，导致查询起来关联的太多，其实订单表设计要考虑到第一时间的呈现方式，经过后面优化，其实最简单的方案就是在订单表冗余几个相关字段，用户名称，商家名称，设备名称即可。可能还涉及到一个数据更新的问题，一般的业务场景主键ID不可修改这个是肯定的，但是有些可以修改用户名称什么的，这个时候可能需要同步更新到订单表的那些冗余字段信息，注意这点就可以。
2.大数据单表多条件查询优化
订单是按月物理分表的，如t_orderhistory201801，t_orderhistory201802，t_orderhistory201803等，查询条件上的查询时间也是控制了只能选择当月的第1天到当月最后一天，随着平台的业务量越来越大，现在又出现一个问题，当选择的查询条件过多，然后选择的时间区间较大比如选择1号到30号，结果查询速度巨慢等很久才出来结果，甚至也会出现查询异常超时现象。问题引起原因我们也清楚，是一个月的订单数据量太大，查询条件过多，区间过大，然后表又做全局扫描，所以导致慢和超时现象，这块要继续优化方案目前有二种。第一种是将月份表继续分表，比如按周，甚至按天尽量压缩查询的仓库。第二种是限制查询的时间区间，比如每次只能查三天的数据或者更小。另外查询条件较多的情况下要做联合索引(组合索引)。目前我们用最快的时间的时间解决暂时先限制查询的时间区间。
另外提下，数据库架构表设计其实和产品设计都密不可分，双方一定要结合起来做设计，有时候产品细节设计要倾向于数据库表设计。
