elasticsearch - mysql多结果集+覆盖索引无法满足需求的时候，有哪些优化sql的方式？什么时候会用到ES？

Question

最初问题的背景是这样：

• 例如对某个客户的报表生成需求，需要查询该客户在特定时间范围内的账单明细

为了简化说明，下面忽略连接查询，则可能的sql如下：

select out_trade_no, payer_id, amount, status, gmt_createfrom orderwhere merchant_id=123 and gmt_create between #{start} and #{end}order by gmt_create desc;

那么至少会需要一个(merchant_id, gmt_create)这样的一个多列索引。
此时因为要查询的字段比较多，所以不可能创建一个很长的多列索引来避免回表查询。而按照我的理解，这样的sql只能在二级索引上查到一条id就回表查询一次，如果gmt_create的范围拉的比较长（比如1个月），则会出现较多的随机IO。

一个能想到的可能优化是通过增加每页可以读取的数据来提高查询效率——延迟关联,那么将sql改为如下：

select o.out_trade_no, o.payer_id, o.amount, o.status, o.gmt_createfrom order as o    inner join (        select id from order        where merchant_id=123 and gmt_create between #{start} and #{end}    ) as sub using(id)order by o.gmt_create desc;

应该是可以进一步提高效率的。

不过最近我发现有些公司会直接使用ES来存储订单/明细表的数据，然后将类似这样的查询（例如报表需求）转发到es上执行，我想知道这样可以进一步提高查询效率吗？还是因为存在别的需求共同导致他们选择了es来代替这类sql查询？

Answer 1

灰机：@唯一丶 另外关于将mysql的订单数据同步到es的情况，我目前总结有两点可能：
商户侧和用户侧的查询订单操作比较多，传统的分库表、查询优化已无法满足，所以用es分担mysql的读压力
有较多且复杂的聚合计算类需求，放到es上执行优势更明显
不知道这两点是否有问题，或者还有补充。
今天 12:13
来自北京
唯一丶：@灰机 我们使用的主要原因也是因为 ES 的查询、聚合更加强大，能较大限度的满足我们的需要，且不用过于的去考虑优化。
对于简单化的查询，仍然是在数据库进行，只是后台运营需要的复杂查询和统计才会放到 ES 端查询。