正文
根据语法树和启发式规则生成分布式执行计划，这个过程会涉及到多个步骤的SQL转换和优化，如条件合并，JOIN拆分，LIMIT转化等；
由SQL执行器按照执行计划和语法树生成下发给每个数据节点的真实SQL，然后通过标准数据库驱动将SQL下发给各个数据节点，这个过程为并发执行；
将各个数据节点返回的结果按照执行计划进行合并，并返回上层。具体的合并操作可能在应用调用结果时动态执行。
DBI模块作为DDB提供给应用的JDBC
驱动，包含了完整的透明分库分表逻辑，是DDB最为核心的组件，除此之外，DDB中还有用于元数据管理和同步的Master组件、数据库管理工具DBAdmin，和命令行工具ISQL，DDB的Driver模式整体架构如图2所示。
图2
管理操作以建表为例：
DBA通过DBAdmin的窗口创建表，或者用ISQL执行建表语句后，向Master发起实际建表请求，Master完成用户认证和合法性校验后，先在各个数据节点上创建新表，然后将新表元数据记录在系统库中，最后由Master将新表元数据同步给各个DBI模块。
对于建表语句中DDB特有的语法，会由ISQL或DBAdmin在解析DDL时完成相应处理，如自增ID的设置。
在DDB中，Master用于元数据管理、同步和报警监控。DBI模块启动时，会第一时间向Master注册，并拉取元数据，之后Master对元数据的同步保障了DBI模块元数据的更新。在DBI执行SQL，以及创建DB连接的过程中，不会涉及到与Master的交互。
在分库分表中间件中，与DDB
Driver模式同样类型的还有阿里TDDL，优势是部署简单、成本较低、容易理解和上手。劣势也非常明显：只支持Java客户端、版本难以管理、问题难以追踪、DB连接难以归敛等，另外一点是，中间件与应用绑定在一起，对应用本身是个巨大侵入，而且分库分表的过程比较耗费CPU资源，所以在Driver模式下，无论是运维还是性能开销上都存在不可控的因素。
Proxy模式
相比于Driver模式在多语言，版本管理，运维风险上存在的问题，Proxy模式很好地弥补了这些缺陷。所谓Proxy，就是在DDB中搭建了一组代理服务器来提供标准的MySQL服务，在代理服务器内部实现分库分表的逻辑。本质上说，DDB
Proxy作为一组独立服务，实现了MySQL标准通信协议，任何语言的MySQL驱动都可以访问，而在Proxy内部，依赖DBI组件实现分库分表，Proxy与DBI的关系如图3所示。
图3
应用通过标准数据库驱动访问DDB Proxy，Proxy内部通过MySQL解码器将请求还原为SQL，并由DDB Driver，也就是DBI模块执行得到结果，最后通过MySQL编码器返回给应用。
从图3可以看出，Proxy在DBI上架设了MySQL编解码模块，从而形成独立标准的MySQL服务，而在MySQL编解码模块之上，DDB Proxy也提供了很多特色命令支持，例如：
-
show processlist：查看Proxy所有连接状态，与MySQL相关命令高度一致
-
show connection_pool：查询Proxy到数据节点的连接池状态
-
showtopsql：查询按照SQL模式聚合的各项统计结果，如执行次数，平均执行时间
-
count..from：查询过去各个时间段内的吞吐量
此外，DDB Proxy内还提供了Slow Log等辅助功能，给运维带来很大的便利。
DDB Proxy模式完整架构如图4所示。
图4
与Driver模式架构相比，除了QS（DDBProxy的内部称谓，下同）取代了DBI的位置，还在多个QS节点之上部署了LVS或HAProxy
+
Keepalived的组合做负载均衡，从而实现多个DDBProxy节点的热备，由于DDBProxy无状态，或者说状态统一由Master同步，在数据库节点没有达到瓶颈时，可以通过简单地增设QS服务器实现服务线性扩展。
私有云模式
