WIP 事务、SQL 执行和结果集处理的设计方案研讨

[flycash]

前提

首先，你需要记住这些点，这是讨论的前提，或者说我们观察到的现象。

• 在 重构：将分库分表的增删改查修改为 DB 维度执行。 #212 里面我说了一个 issue，就是在事务里面并不能并发执行语句，必须要前一个语句的结果集处理完了，才能执行下一个语句。举个例子，我们不能在一个事务并发执行两个 SELECT 语句。
• 在分库分表里面，目标语句执行可以考虑按照表维度执行，也可以按照 DB 维度执行。
• 在分库分表的延迟分布式事务里面，我们希望同一个 DB 只有一个本地事务。
• 在结果集处理里面，我们在排序、分页和去重里面都用了类似于归并排序的优化技术，这是为了避免一次性读取全部结果集，造成巨大的内存压力

现在，我们就要考虑，究竟按照什么维度来调度 SQL 执行，是 DB 维度还是表维度？我举个例子：假如说现在一个 SELECT 语句命中了四个表，db_0.tab_0, db_0.tab_1 和 db_1.tab_0, db_1.tab_1，

• 那么表维度的意思就是，我们会并发发送四个 SQL 请求
• 如果是 DB 维度，那么我们就会发送两个请求 SELECT db_0.tab0;SELECT db_0.tab1; 和 SELECT db_1.tab0;SELECT db_1.tab1;

如果是表维度，那么事务问题怎么解决？
如果是 DB 维度，那么结果集处理的性能问题怎么解决？

可行方案

这个是没得选的。事务：

1. 受制于事务，只能按照 DB 维度调度执行目标语句。
2. 如果真的是多个语句，那么不能执行归并排序类的性能优化。影响排序、分页、去重、分组这几个功能的实现。

方案1

优先

1. 非事务的话，就可以表维度执行。可以全部运用归并排序来优化性能
2. 事务，DB 维度执行，无法运用归并排序来优化性能

方案2

都是 DB 维度执行，然后尽量运用归并排序。

合并 DB 维度

buildQuery VS executeStrategy

谁来决定要不要归并排序