正文
视频教程：https://doc.iocoder.cn/video/
数据节点是数据分片中一个不可再分的最小单元（表），它由数据源名称和数据表组成，例如上图中
DB_1.t_order_1
、
DB_2.t_order_2
就表示一个数据节点。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
-
项目地址：https://github.com/YunaiV/yudao-cloud
-
视频教程：https://doc.iocoder.cn/video/
逻辑表是指具有相同结构的水平拆分表的逻辑名称。
比如我们将订单表
t_order
分表拆分成
t_order_0
···
t_order_9
等10张表，这时我们的数据库中已经不存在
t_order
这张表，取而代之的是若干的
t_order_n
表。
分库分表通常对业务代码都是无侵入式的，开发者只专注于业务逻辑SQL编码，我们在代码中
SQL
依然按
t_order
来写，而在执行逻辑SQL前将其解析成对应的数据库真实执行的SQL。此时 t_order 就是这些拆分表的
逻辑表
。
业务逻辑SQL
select * from t_order where order_no='A11111'
真实执行SQL
select * from DB_1.t_order_n where order_no='A11111'
真实表就是在数据库中真实存在的物理表
DB_1.t_order_n
。
广播表是一类特殊的表，其表结构和数据在所有分片数据源中均完全一致。与拆分表相比，广播表的数据量较小、更新频率较低，通常用于字典表或配置表等场景。由于其在所有节点上都有副本，因此可以大大降低
JOIN
关联查询的网络开销，提高查询效率。
需要注意的是，对于广播表的修改操作需要保证同步性，以确保所有节点上的数据保持一致。
广播表的特点
：
-
在所有分片数据源中，广播表的数据完全一致。因此，对广播表的操作（如插入、更新和删除）会实时在每个分片数据源中执行一遍，以保证数据的一致性。
-
对于广播表的查询操作，仅需要在任意一个分片数据源中执行一次即可。
-
与任何其他表进行JOIN操作都是可行的，因为由于广播表的数据在所有节点上均一致，所以可以访问到任何一个节点上的相同数据。
订单管理系统中，往往需要查询统计某个城市地区的订单数据，这就会涉及到省份地区表
t_city
与订单流水表
DB_n
.
t_order_n
进行JOIN查询，因此可以考虑将省份地区表设计为
广播表
，核心理念就是
避免跨库JOIN操作
。
注意
：上边我们提到广播表在数据插入、更新与删除会实时在每个分片数据源均执行，也就是说如果你有1000个分片数据源，那么修改一次广播表就要执行1000次SQL，所以尽量不在并发环境下和业务高峰时进行，以免影响系统的性能。
单表指所有的分片数据源中仅唯一存在的表（没有分片的表），适用于数据量不大且无需分片的表。
如果一张表的数据量预估在千万级别，且没有与其他拆分表进行关联查询的需求，建议将其设置为单表类型，存储在默认分片数据源中。
分片键决定了数据落地的位置，也就是数据将会被分配到哪个数据节点上存储。因此，分片键的选择非常重要。
比如我们将
t_order
表进行分片后，当插入一条订单数据执行SQL时，需要通过解析SQL语句中指定的分片键来计算数据应该落在哪个分片中。以表中
order_no
字段为例，我们可以通过对其取模运算（比如
order_no % 2
）来得到分片编号，然后根据分片编号分配数据到对应的数据库实例（比如
DB_1
和
DB_2
）。拆分表也是同理计算。
在这个过程中，
order_no
就是
t_order
表的分片键。也就是说，每一条订单数据的
order_no
值决定了它应该存放的数据库实例和表。选择一个适合作为分片键的字段可以更好地利用水平分片带来的性能提升。
这样同一个订单的相关数据就会落在同一个数据库、表中，查询订单时同理计算，就可直接定位数据位置，大幅提升数据检索的性能，避免了全库表扫描。
不仅如此
ShardingSphere
还支持根据多个字段作为分片健进行分片，这个在后续对应章节中会详细讲。
分片策略来指定使用哪种分片算法、选择哪个字段作为分片键以及如何将数据分配到不同的节点上。
分片策略是由
分片算法
和
分片健
组合而成，分片策略中可以使用多种分片算法和对多个分片键进行运算。
