分库分表之实战-sharding-JDBC广播表

工藤学编程

发布于 2025-12-22 09:04:23

170

大家好，我是工藤学编程 🦉	一个正在努力学习的小博主，期待你的关注
实战代码系列最新文章😉	C++实现图书管理系统（Qt C++ GUI界面版）
SpringBoot实战系列🐷	【SpringBoot实战系列】Sharding-Jdbc实现分库分表到分布式ID生成器Snowflake自定义wrokId实战
环境搭建大集合	环境搭建大集合(持续更新）
分库分表	分库分表之实战-sharding-JDBC

前情摘要：

1、数据库性能优化 2、分库分表之优缺点分析 3、分库分表之数据库分片分类 4、分库分表之策略 5、分库分表技术栈讲解-Sharding-JDBC 6、分库分表下的 ID 冲突问题与雪花算法讲解 7、分库分表之实战-sharding-JDBC

【亲测宝藏推荐】发现一个让 AI 学习秒变轻松的神站！不用啃高数、不用怕编程，高中生都能看懂的人工智能教程来啦！

👉点击跳转，和 thousands of 小伙伴一起用快乐学习法征服 AI，说不定下一个开发出爆款 AI 程序的就是你！

Sharding-JDBC广播表深度解析与实战配置指南

一、广播表核心概念与设计思想

在分布式分库分表场景中，当我们需要处理海量数据时，通常会将大表按规则拆分到多个数据库/表中。但对于一类特殊的表——广播表（Broadcast Table），它有着完全不同的设计逻辑：定义：所有分片数据源中都存在的表，其表结构和数据在每个数据库实例中完全一致。就像“广播”一样，数据会同步到所有分片节点，确保任何数据源访问时都能获取到相同的表结构和数据。

核心特性：

数据一致性：所有分片库的表结构、数据完全相同
无分片逻辑：不参与分库分表规则，直接全库复制
关联查询优化：避免跨库关联，提升多表join性能

二、适用场景与典型案例

为什么需要广播表？当我们遇到以下场景时，广播表能发挥关键作用： 典型场景：

字典表/配置表：如性别字典、状态码表、系统参数表等（数据量小但高频访问）
基础信息表：如行政区划表、部门表（数据稳定且需要与业务表频繁关联）
维度表：在数据仓库场景中作为维度表存在

优势对比：假设订单表按用户分库，若商品表作为普通分片表，订单与商品的关联查询需要跨库路由；而商品表作为广播表时，每个分片库都有完整商品数据，可直接在本地库完成join，省去复杂的跨库关联逻辑。

注意！这些场景不适用：

数据量大且频繁更新的表（全库同步成本高）
业务上需要独立分片的表（如用户表、订单表）

三、Sharding-JDBC配置实战（以Spring Boot为例）

在分库分表之实战-sharding-JDBC基础上

我们需要在数据库ccc_shop_order_0、ccc_shop_order_1中分表新建下表：

CREATE TABLE `ad_config` (
  `id` bigint unsigned NOT NULL COMMENT '主键id',
  `config_key` varchar(1024) COLLATE utf8mb4_bin 
DEFAULT NULL COMMENT '配置key',
  `config_value` varchar(1024) COLLATE utf8mb4_bin 
DEFAULT NULL COMMENT '配置value',
  `type` varchar(128) COLLATE utf8mb4_bin DEFAULT 
NULL COMMENT '类型',
  PRIMARY KEY (`id`)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 
COLLATE=utf8mb4_bin;

然后新建pojo类：

@Data
 @EqualsAndHashCode(callSuper = false)
 @TableName("ad_config")
 public class AdConfigDO {
    private Long id;
    private String configKey;
    private String configValue;
    private String type;
 }

然后在application.properties中添加广播包配置：

spring.shardingsphere.sharding.broadcast-tables=ad_config
spring.shardingsphere.sharding.tables.ad_config.key-generator.column=id
spring.shardingsphere.sharding.tables.ad_config.key-generator.type=SNOWFLAKE

然后再新建对应的Mapper

public interface AdConfigMapper extends
        BaseMapper<AdConfigDO> {
}

最后在单元测试类，DbTest中新增单元测试函数

@Test
    public void testSaveAdConfig(){
        AdConfigDO adConfigDO = new AdConfigDO();
        adConfigDO.setConfigKey("ad_config_key");
        adConfigDO.setConfigValue("编程接单找CCC");
        adConfigDO.setType("ad");
        adConfigMapper.insert(adConfigDO);
    }

当前项目目录如下，大家可以对比：

然后运行该单元函数，查看结果

2025-07-01 15:53:52.221  INFO 5636 --- [           main] ShardingSphere-SQL                       : Actual SQL: ds0 ::: INSERT INTO ad_config  ( id,
config_key,
config_value,
type )  VALUES  (?, ?, ?, ?) ::: [1939955597112029186, ad_config_key, 编程接单找CCC, ad]
2025-07-01 15:53:52.221  INFO 5636 --- [           main] ShardingSphere-SQL                       : Actual SQL: ds1 ::: INSERT INTO ad_config  ( id,
config_key,
config_value,
type )  VALUES  (?, ?, ?, ?) ::: [1939955597112029186, ad_config_key, 编程接单找CCC, ad]

可以看到我们的两个库中的两个表数据都被插入的是相同的数据

四、避坑指南与最佳实践

字段命名规范
- 严格避免使用SQL关键字（如desc、order、limit），Sharding-JDBC对关键字的兼容性较弱，报错信息可能不明确
- 示例：字段名desc会导致SQL解析错误，应改为description
表结构变更注意事项
- 任何表结构变更（如新增字段）必须同步执行到所有分片库
- 推荐使用版本控制工具（如Liquibase）管理多库DDL变更
性能优化技巧
- 广播表本身无需分片键，建表时可移除分片键相关索引
- 对于极小表（如100条以内），可关闭Sharding-JDBC的优化器逻辑（通过props.sql.optimizer.enable配置）
监控与治理
- 通过ShardingSphere的治理中心（如ZooKeeper）监控广播表同步状态
- 结合APM工具（如SkyWalking）追踪跨库关联性能变化