阿里巴巴数据库分库分表的实践

此时就出现了我们所说的全表扫描。此时我们来解释一下这里“事务边界”的定义，所谓的事务边界即是指单个SQL语句在后端数据库上同时执行的数量，上面示例中就是事务边界大的典型示例，即一条SQL语句同时被推送到后端所有数据库中运行。事务边界的数量越大，会给系统带来以下弊端：

系统的锁冲突概率越高。如果事务边界大的SQL请求比较多，在一次SQL请求处理过程中自然对于后端的数据库操作的数据库记录覆盖比较广，当有多个类似的SQL请求并行执行时，则出现数据锁造成的资源访问互斥的概率会大大增加。

系统越难以扩展。如果有大量的SQL请求都是这样全表扫描，或者从极端角度说明这个问题，如果每一次的SQL请求都需要全表扫描执行，你会发现整个平台的数据库连接数量是取决于后端单个数据库的连接能力，也就意味着整个数据库的能力是无法通过增加后端数据库实例来扩展的。所以如果有大量的全表扫描的SQL请求对于系统的扩展能力会带来不小的影响。

整体性能越低。对于性能，这里想强调的是对系统整体性能的影响，而不是单次SQL的性能。应用发送获取买家test1订单列表SQL的请求（如图5-8步骤①）时，分布式数据层会并行的将这条SQL语句推送（如图5-8步骤②）到后端8台数据库上运行，因为订单数据进行了平均的拆分，单个数据库订单表的数据量大小都使得数据库处于最佳性能表现的状态，所以意味着每一个数据库返回的计算结果都是在一个可期望的时间内（比如100毫秒），将结果返回到分布式数据层（如图5-8步骤③），分布式数据层将从各个数据库返回来的结果在内存中进行聚合或排序等操作（如图5-8步骤④），最后返回订单列表给应用（如图5-8步骤⑤）。

图5-8DRDS对需全表扫描操作的SQL请求处理流程

整个SQL执行的过程包含了5个步骤，仔细看看，你会发现一次带分库分表键执行的SQL过程也会经历这5个步骤，区别只是在②③步骤是并行的方式同时跟多个后端数据库进行交互，但在时间上带来的影响几乎是毫秒级的；而第④个步骤是可能造成差异的一个点，如果像示例中一个用户的订单信息可能最多几千条，对于几千条数据的内存聚合操作，处理时间也是毫秒级的，所以这样一次全表扫描的操作，用户的体验是完全无感知的，跟访问单机数据库的体验是没有差异的。但如果在第④个步骤中确实遇到对大数据量（比如几十万、几百万条数据）的聚合、排序、分组等计算时，则会占用较大的内存和CPU计算资源，如果这样类型的SQL请求比较频繁的话，就会给分布式数据层带来较大的资源占用，从而导致整体分布式服务的处理性能受到影响。

（编辑：西安站长网）

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