分库分表的21条法则速来码住（下）

SQL 解析

分库分表后在应用层面执行一条 SQL 语句时，通常需要经过以下六个步骤：SQL 解析 -> 执⾏器优化 -> SQL 路由 -> SQL 改写 -> SQL 执⾏ -> 结果归并 。

在这里插入图片描述

SQL解析过程分为词法解析和语法解析两步，比如下边查询用户订单的SQL，先用词法解析将这条SQL拆解成不可再分的原子单元。在根据不同数据库方言所提供的字典，将这些单元归类为关键字，表达式，变量或者操作符等类型。

SELECT order_no FROM t_order where  order_status > 0  and user_id = 10086

接着语法解析会将拆分后的SQL关键字转换为抽象语法树，通过对抽象语法树遍历，提炼出分片所需的上下文，上下文包含查询字段信息（Field）、表信息（Table）、查询条件（Condition）、排序信息（Order By）、分组信息（Group By）以及分页信息（Limit）等，并标记出 SQL中有可能需要改写的位置。

抽象语法树

执⾏器优化

执⾏器优化是根据SQL查询特点和执行统计信息，选择最优的查询计划并执行，比如user_id字段有索引，那么会调整两个查询条件的位置，主要是提高SQL的执行效率。

SELECT order_no FROM t_order where user_id = 10086 and order_status > 0

SQL 路由

通过上边的SQL解析得到了分片上下文数据，在匹配用户配置的分片策略和算法，就可以运算生成路由路径，将 SQL 语句路由到相应的数据节点上。

简单点理解就是拿到分片策略中配置的分片键等信息，在从SQL解析结果中找到对应分片键字段的值，计算出 SQL该在哪个库的哪个表中执行，SQL路由又根据有无分片健分为 分片路由 和 广播路由。

有分⽚键的路由叫分片路由，细分为直接路由、标准路由和笛卡尔积路由这3种类型。

标准路由

标准路由是最推荐也是最为常⽤的分⽚⽅式，它的适⽤范围是不包含关联查询或仅包含绑定表之间关联查询的SQL。

当 SQL分片健的运算符为 = 时，路由结果将落⼊单库（表），当分⽚运算符是BETWEEN 或IN 等范围时，路由结果则不⼀定落⼊唯⼀的库（表），因此⼀条逻辑SQL最终可能被拆分为多条⽤于执⾏的真实SQL。

SELECT * FROM t_order  where t_order_id in (1,2)

SQL路由处理后

SELECT * FROM t_order_0  where t_order_id in (1,2)
SELECT * FROM t_order_1  where t_order_id in (1,2)

直接路由

直接路由是直接将SQL路由到指定⾄库、表的一种分⽚方式，而且直接路由可以⽤于分⽚键不在SQL中的场景，还可以执⾏包括⼦查询、⾃定义函数等复杂情况的任意SQL。

笛卡尔积路由

笛卡尔路由是由⾮绑定表之间的关联查询产生的，比如订单表t_order 分片键是t_order_id和用户表t_user分片键是t_order_id，两个表的分片键不同，要做联表查询，会执行笛卡尔积路由，查询性能较低尽量避免走此路由模式。

SELECT * FROM t_order_0 t LEFT JOIN t_user_0 u ON u.user_id = t.user_id WHERE t.user_id = 1
SELECT * FROM t_order_0 t LEFT JOIN t_user_1 u ON u.user_id = t.user_id WHERE t.user_id = 1
SELECT * FROM t_order_1 t LEFT JOIN t_user_0 u ON u.user_id = t.user_id WHERE t.user_id = 1
SELECT * FROM t_order_1 t LEFT JOIN t_user_1 u ON u.user_id = t.user_id WHERE t.user_id = 1

无分⽚键的路由又叫做广播路由，可以划分为全库表路由、全库路由、 全实例路由、单播路由和阻断路由这 5种类型。

全库表路由

全库表路由针对的是数据库 DQL和 DML，以及 DDL等操作，当我们执行一条逻辑表 t_order SQL时，在所有分片库中对应的真实表 t_order_0 ··· t_order_n 内逐一执行。

全库路由

全库路由主要是对数据库层面的操作，比如数据库 SET 类型的数据库管理命令，以及 TCL 这样的事务控制语句。

对逻辑库设置 autocommit 属性后，所有对应的真实库中都执行该命令。

SET autocommit=0;

全实例路由

全实例路由是针对数据库实例的 DCL 操作（设置或更改数据库用户或角色权限），比如：创建一个用户 order ，这个命令将在所有的真实库实例中执行，以此确保 order 用户可以正常访问每一个数据库实例。

CREATE USER order@127.0.0.1 identified BY '程序员小富';

单播路由

单播路由用来获取某一真实表信息，比如获得表的描述信息：

DESCRIBE t_order;

t_order 的真实表是 t_order_0 ···· t_order_n，他们的描述结构相完全同，我们只需在任意的真实表执行一次就可以。

阻断路由

⽤来屏蔽SQL对数据库的操作，例如：

USE order_db;

这个命令不会在真实数据库中执⾏，因为 ShardingSphere 采⽤的是逻辑 Schema（数据库的组织和结构） ⽅式，所以无需将切换数据库的命令发送⾄真实数据库中。

SQL 改写

SQL经过解析、优化、路由后已经明确分片具体的落地执行的位置，接着就要将基于逻辑表开发的SQL改写成可以在真实数据库中可以正确执行的语句。比如查询 t_order 订单表，我们实际开发中 SQL是按逻辑表 t_order 写的。

SELECT * FROM t_order

这时需要将分表配置中的逻辑表名称改写为路由之后所获取的真实表名称。

SELECT * FROM t_order_n

SQL执⾏

将路由和改写后的真实 SQL 安全且高效发送到底层数据源执行。但这个过程并不能将 SQL 一股脑的通过 JDBC 直接发送至数据源执行，需平衡数据源连接创建以及内存占用所产生的消耗，它会自动化的平衡资源控制与执行效率。

结果归并

将从各个数据节点获取的多数据结果集，合并成一个大的结果集并正确的返回至请求客户端，称为结果归并。而我们SQL中的排序、分组、分页和聚合等语法，均是在归并后的结果集上进行操作的。

分布式主键

数据分⽚后，一个逻辑表（t_order）对应诸多的真实表（t_order_n），它们之间由于⽆法互相感知，主键ID都从初始值累加，所以必然会产⽣重复主键ID，此时主键不再唯一那么对于业务来说也就没意义了。

尽管可通过设置表⾃增主键 初始值 和 步⻓ 的⽅式避免ID碰撞，但这样会使维护成本加大，可扩展性差。

这个时候就需要我们手动为一条数据记录，分配一个全局唯一的ID，这个ID被叫做分布式ID，而生产这个ID的系统通常被叫做发号器。

大家可以参考我之前发布的这篇文章 9种分布式ID生成方案

数据脱敏

分库分表数据脱敏是一种有效的数据保护措施，可以确保敏感数据的机密性和安全性，减少数据泄露的风险。

比如，我们在分库分表时可以指定表的哪些字段为脱敏列，并设置对应的脱敏算法，在数据分片时解析到执行SQL中有待脱敏字段，会直接将字段值脱敏后的写入库表内。

对于用户的个人信息，如姓名、地址和电话号码等，可以通过加密、随机化或替换成伪随机数据的方式进行脱敏，以确保用户的隐私得到保护。

大家可以参考我之前发布的这篇文章 大厂也在用的 6种 数据脱敏方案

分布式事务

分布式事务的核心问题是如何实现跨多个数据源的原子性操作。

由于不同的服务通常会使用不同的数据源来存储和管理数据，因此，跨数据源的操作可能会导致数据不一致性或丢失的风险。因此，保证分布式事务的一致性是非常重要的。

以订单系统为例，它需要调用支付系统、库存系统、积分系统等多个系统，而每个系统都维护自己的数据库实例，系统间通过API接口交换数据。

为了保证下单后多个系统同时调用成功，可以使用强一致性事务的XA协议，或者柔性事务的代表工具Seata，来实现分布式事务的一致性。这些工具可以帮助开发人员简化分布式事务的实现，减少错误和漏洞的出现，提高系统的稳定性和可靠性。

经过分库分表之后，问题的难度进一步提升。自身订单服务，也需要处理跨数据源的操作。这样一来，系统的复杂度显著增加。因此，不到万不得已的情况下，最好避免采用分库分表的解决方案。

关于分布式事务详细的介绍，大家可以参考我之前发布的这篇文章 对比 5 种分布式事务方案，还是宠幸了阿里的 Seata（原理 + 实战）

数据迁移

分库分表后还有个让人头疼的问题，那就是数据迁移，为了不影响现有的业务系统，通常会新建数据库集群迁移数据。将数据从旧集群的数据库、表迁移到新集群的分库、分表中。这是一个比较复杂的过程，在迁移过程中需要考虑数据量、数据一致性、迁移速度等诸多因素。

迁移主要针对 存量数据 和 增量数据 的处理，存量数据指旧数据源中已经存在且有价值的历史数据，增量数据指当下持续增长以及未来产生的业务数据。

存量数据可以采用定时、分批次的迁移，迁移过程可能会持续几天。

增量数据可以采用新、旧数据库集群双写模式。待数据迁移完毕，业务验证了数据一致性，应用直接切换数据源即可。

后续我们会结合三方工具，来演示迁移的过程。

影子库

什么是影子库（Shadow Table）？

影子库是一个与生产环境数据库结构完全相同的实例，它存在的意义是为了在不影响线上系统的情况下，验证数据库迁移或者其他数据库变更操作的正确性，以及全链路压测。影子库中存储的数据是从生产环境中定期复制过来的，但是它不对线上业务产生任何影响，仅用于测试，验证和调试。

在进行数据库升级、版本变更、参数调优等操作前，通过在影子库上模拟这些操作，可以发现潜在的问题，因为测试环境的数据是不可靠的。

在使用影子库时，需要遵循以下几个原则：

• 与生产环境数据库的结构应该完全一致，包括表结构、索引、约束等；
• 数据要与生产环境保持一致，可以通过定期同步方式实现；
• 读写操作不会影响生产环境，一般情况下应该禁止在影子库上执行更新、删除等操作；
• 由于影子库的数据特点，访问权限应该严格控制，只允许授权人员进行访问和操作；

总结

本文介绍了关于分库分表架构的21个通用概念，有一定的了解之后，接下来我们将进入更深度的内容，包括读写分离、数据脱敏、分布式主键、分布式事务、配置中心、注册中心、Proxy服务等实战案例的讲解和源码分析。