MySQL中的SQL优化建议那么多

是不满足需求的，想看看我们有没有优化的建议。

第一印象这条SQL执行时长200~500毫秒，要优化好像可打的牌不多啊,如果要想得到一个可接受的基准值，当然反馈会是越快越好。所以从这个角度来看，我们不妨按照毫秒级优化的标准来看，这条SQL需要做哪些补充的工作。

首先通过SQL看下逻辑情况，整体的逻辑是按照用户id去查询两个数据源(trade_order和virtual_order)，从两个数据源查询出10条单号数据返回。这个用户在两个数据源中可能有单号，也可能没有，只要有匹配的就返回，累计返回10条，看起来是为了去重才选择了union的组合方式。

先不看表结构信息，我大体有了如下的建议：

1. union的模式更建议采用union all,两个数据源存在数据重合应该是不合理的。
2. 查询语句里面使用了order_time但是数据返回压根没有用到，建议去掉
3. SQL层面承载了太多的数据处理压力，比如多数据源，去重和过滤，分页，是不是可以做下精简。

当然到了这里，和业务的需求就产生了脱节，这就属于那种看啥都不顺眼的状态，总想找出点问题来，而且对于业务同学来说，哪怕十个八个需求，你得有一个需求的收益更高，他们采用其他需求的可能性才越大，否则就是不作为了。

所以到了这里，我们开始做下分析，要优化SQL不看看执行计划是不过关的，在执行前，我的大体感觉表数据量很大，应该是生成了派生表，然后在数据去重过滤层面的消耗比较大，而两个子查询来说，返回的结果集应该很少。 预测的执行情况是：

1)子查询trade_order应该很快，毫米级响应

2)子查询virtual_order应该也很快，但是最后有一个order by操作，可能代价略高

3)union的去重过滤代价相对较大，涉及到两个结果集的合并，如果返回结果较多，可能是瓶颈

从执行结果来看，让我有些意外，其中virtual_order的返

（编辑：保山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!