拆分表的SQL转发
针对各种sql语句，中间件内部是如何处理的
解析出带有In的sql语句，内部根据分库分表原则，拆分成多个sql，然后发送到不同的节点上去
等待不同的节点数据全部返回之后，再合并结果，然后根据协议拼接返回的数据
- 跨库join是笛卡尔积的数据计算量，如果数据量稍大，系统就会将任务拒绝掉，否则系统就会崩溃
- 跨库join计算量太大，不适合实时系统的处理
- 如果加上主键索引字段查询,那样计算量就会缩小很多
- 如果两个库关联较大，应该采取相同的DB分片规则，放在同一个库中处理
- 小表广播策略
禁止使用跨库join
OrderBy limit
-
当sql为order limit时，必须全表扫描，去拿每个节点的limit+offset的排序数据，然后针对所有的数据结果进行重排序，最终拿到2需要的2个数据返回，当然可以排序算法上面可以做一些优化。
-
这样的计算量非常大，当limit最后的排序数据时，需要返回的数据量更是大得惊人，所以可以使用es来解决这个查询问题
Group By
事务支持
- 如果是同库事务，支持
- 如果是不同库事务，DB在commit之前，任何失败，全部失败。
- 如果是不同库事务，前一个commit成功，后一个commit可能会失败，事务弱一致性
