分库分表之实战-sharding-JDBC水平分库+分表后:查询与删除操作实战

大家好,我是工藤学编程 🦉 一个正在努力学习的小博主,期待你的关注
实战代码系列最新文章😉 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
8、分库分表之实战-sharding-JDBC广播表
9、分库分表之实战-sharding-JDBC水平分库+水平分表配置实战
10、分库分表之实战-sharding-JDBC绑定表配置实战


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

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


本文章目录

  • 水平分库+分表后:查询与删除操作实战
    • 一、知识回顾:分库分表路由核心
    • [二、查询操作实战:有分片键 vs 无分片键](#二、查询操作实战:有分片键 vs 无分片键)
      • [1. 有分片键的查询(标准路由)](#1. 有分片键的查询(标准路由))
        • [(1)= 条件查询(单分片键)](#(1)= 条件查询(单分片键))
        • [(2)IN 条件查询(多分片键)](#(2)IN 条件查询(多分片键))
      • [2. 无分片键的查询(全库表路由)](#2. 无分片键的查询(全库表路由))
    • 三、删除操作实战
      • [1. 有分片键的删除(标准路由)](#1. 有分片键的删除(标准路由))
        • [(1)= 条件删除](#(1)= 条件删除)
        • [(2)IN 条件删除](#(2)IN 条件删除)
      • [2. 无分片键的删除(全库表路由)](#2. 无分片键的删除(全库表路由))
    • 四、路由原理:Sharding-Jdbc如何决定路由规则?
    • 五、最佳实践与避坑指南
      • [1. 优先使用「有分片键」的操作](#1. 优先使用「有分片键」的操作)
      • [2. 谨慎使用`IN`条件](#2. 谨慎使用IN条件)
      • [3. 无分片键删除的安全操作](#3. 无分片键删除的安全操作)
      • [4. 结合索引优化查询](#4. 结合索引优化查询)
      • [5. 注意事务一致性](#5. 注意事务一致性)
    • 六、总结

水平分库+分表后:查询与删除操作实战

在水平分库+分表架构中,CRUD操作的路由逻辑直接影响系统性能与数据准确性。本文聚焦查询删除操作,通过实战案例解析「有分片键」和「无分片键」场景下的路由规则,结合Sharding-Jdbc的实现原理,总结高效操作的最佳实践。

一、知识回顾:分库分表路由核心

先明确本文的分库分表规则(以订单表product_order为例):

  • 分库策略 :按user_id取模(2个库:ds0ds1
  • 分表策略 :按id取模(每个库分2张表:t0t1
  • 完整表名格式:ds${user_id % 2}.product_order_${id % 2}

核心概念

  • 分片键 :决定数据路由的字段(本文中user_id为分库键,order_id为分表键,统称「分片键」)
  • 标准路由:有明确分片键时,精准定位到目标库表(高效)
  • 全库表路由:无分片键时,扫描所有库表(低效,需避免)

二、查询操作实战:有分片键 vs 无分片键

查询操作的路由逻辑是分库分表中最常接触的场景,也是性能优化的关键。

1. 有分片键的查询(标准路由)

当查询条件中包含分库键或分表键时,Sharding-Jdbc会通过「标准路由」精准定位目标库表,避免全扫描。

(1)= 条件查询(单分片键)

在DbTest中新增测试函数

sql 复制代码
@Test
    public void testPartitionKeyQuery(){
        List<ProductOrderDO> list = productOrderMapper.selectList(new QueryWrapper<ProductOrderDO>().eq("id", 1942559776326320130L));
    }

结果只会发出两条sql
路由过程

  • 计算分表:id=1942559776326320130 % 2 = 0 → 目标表为product_order_t0
  • 分库键user_id未指定,需扫描所有分库的product_order_t0
  • 实际执行:ds0.product_order_t0ds1.product_order_t0各查1次

在DbTest中新增测试函数(同时包含分库键user_id和分表键order_id):

sql 复制代码
@Test
    public void testTwoPartitionKeyQuery(){
        List<ProductOrderDO> list = productOrderMapper.selectList(new QueryWrapper<ProductOrderDO>().eq("id", 1942559776326320130L)
                .eq("user_id", 204402002533403893L));
    }

结果只会发出1条sql

路由过程

  • 分库:user_id=204402002533403893 % 2 = 1 → 目标库ds1
  • 分表:id=1942559776326320130 % 2 = 0 → 目标表product_order_t0`
  • 实际执行:仅查询 ds1.product_order_t0(1次操作,最优路由)
(2)IN 条件查询(多分片键)

在DbTest中新增测试函数(分表键idIN查询):

sql 复制代码
@Test
    public void testPartitionKeyInQuery(){
        List<ProductOrderDO> list = productOrderMapper.selectList(new QueryWrapper<ProductOrderDO>().in("id", Arrays.asList(1942559776326320130L, 1942559779014868995L))
        );
    }

执行结果

路由过程

  • order_id=1942559776326320130 % 2 = 0 → 表product_order_t0
  • order_id=1942559779014868995 % 2 = 1 → 表product_order_t1
  • 分库键user_id未指定,需扫描所有分库的t0t1
  • 实际执行:ds0.t0ds0.t1ds1.t0ds1.t1(4次操作,按分表键拆分后路由)

2. 无分片键的查询(全库表路由)

当查询条件中不包含任何分片键时,Sharding-Jdbc会执行「全库表路由」,即扫描所有分库分表。

在DbTest中新增测试函数(仅按非分片键out_trade_no查询):

sql 复制代码
 @Test
    public void testNoPartitionKeyQuery(){
        List<ProductOrderDO> list = productOrderMapper.selectList(new QueryWrapper<ProductOrderDO>().eq("out_trade_no", "70bd5220-1c9c-4e3e-b418-85481f60")
        );
    }

路由过程

  • user_idid,无法定位分库分表
  • 实际执行:查询所有4张表(ds0.t0ds0.t1ds1.t0ds1.t1),并合并结果

问题与风险

  • 性能损耗:全表扫描次数 = 分库数 × 分表数(本例4次,分表越多损耗越大)
  • 数据一致性 :若表中存在重复数据(如不同分片有相同out_trade_no=70bd5220-1c9c-4e3e-b418-85481f60的记录),需业务层保证逻辑唯一

三、删除操作实战

删除操作的路由逻辑与查询基本一致,但需额外注意数据安全(尤其是无分片键时)。

1. 有分片键的删除(标准路由)

(1)= 条件删除

在DbTest中新增测试函数(按分库键+分表键删除):

sql 复制代码
@Test
    public void testTwoPartitionKeyDelete(){
        productOrderMapper.delete(new QueryWrapper<ProductOrderDO>().eq("id", 1942559776326320130L)
                .eq("user_id", 204402002533403893L));
    }

执行结果

路由过程

  • 定位到ds1.product_order_t0(1次删除,精准高效)
(2)IN 条件删除

在DbTest中新增测试函数(按分表键批量删除):

sql 复制代码
@Test
    public void testPartitionKeyInDelete(){
        productOrderMapper.delete(new QueryWrapper<ProductOrderDO>().in("id", Arrays.asList(1942559776326320130L, 1942559779014868995L))
        );
    }

执行结果

路由过程

  • 分表:1942559776326320130→t01942559779014868995→t1,但无分库键user_id
  • 实际执行:删除ds0.t0ds0.t1ds1.t0ds1.t1中符合条件的记录(4次操作)

2. 无分片键的删除(全库表路由)

在DbTest中新增测试函数:

sql 复制代码
@Test
    public void testNoPartitionKeyDelete(){
        productOrderMapper.delete(new QueryWrapper<ProductOrderDO>().eq("out_trade_no", "70bd5220-1c9c-4e3e-b418-85481f60")
        );
    }

执行结果

路由过程

  • 扫描所有4张表,执行删除操作
  • 风险提示 :无分片键的删除可能导致「误删全量数据」,建议先通过查询验证数据范围,再执行删除(可加LIMIT限制条数)

四、路由原理:Sharding-Jdbc如何决定路由规则?

Sharding-Jdbc的路由逻辑基于「分片键提取→分片算法计算→目标库表定位」三步:

  1. 提取分片键 :从SQL的WHERE条件中解析分库键(如user_id)和分表键(如order_id
  2. 计算分片:调用配置的分片算法(如取模、哈希),得到目标库索引和表索引
  3. 生成路由:若有完整分片键,生成「标准路由」;若缺失,生成「全库表路由」

五、最佳实践与避坑指南

1. 优先使用「有分片键」的操作

  • 所有查询和删除尽量携带分库键或分表键(至少携带一个),避免全库表扫描

2. 谨慎使用IN条件

  • IN中的值不宜过多(建议≤10个),否则会触发多表路由,性能接近全扫描

3. 无分片键删除的安全操作

  • 必须执行时,先通过SELECT COUNT(*)预估数据量,确认后再删除
  • LIMIT限制单次删除条数:DELETE FROM product_order WHERE status=3 LIMIT 1000;

4. 结合索引优化查询

  • 分表的分片键必须建索引(如id),避免单表内全扫描
  • 非分片键查询需配合分表键使用,例:WHERE user_id=1 AND out_trade_no=1(先定位库,再查订单号)

5. 注意事务一致性

  • 跨分片删除会触发分布式事务,建议通过「分片键+本地事务」避免(如按user_id批量删除)

六、总结

水平分库分表后的查询和删除操作,核心是对分片键的依赖程度

  • 「有分片键」→ 标准路由,高效精准,推荐使用
  • 「无分片键」→ 全库表路由,低效且有风险,谨慎使用

实际开发中,应通过业务设计强制分片键的使用(如API接口必须传入user_idorder_id),同时结合监控工具(如Sharding-Jdbc的SQL日志)跟踪路由情况,及时优化不合理的操作。

觉得有用请点赞收藏!

如果有相关问题,欢迎评论区留言讨论~

相关推荐
天南星2 分钟前
java-WebSocket在Java生态中的发展历程
java·后端·websocket
天翼云开发者社区15 分钟前
OLAP分析数据库适用场景及主流产品对比
数据库
Britz_Kevin17 分钟前
从零开始的云计算生活——番外2,MySQL组复制
数据库·mysql·云计算·生活·#组复制
工藤学编程27 分钟前
分库分表之实战-sharding-JDBC绑定表配置实战
数据库·分布式·后端·sql·mysql
写不出来就跑路37 分钟前
SpringBoot静态资源与缓存配置全解析
java·开发语言·spring boot·spring·springboot
fmvrj342021 小时前
云原生:数字化转型的核心引擎
后端
码出极致1 小时前
Redisson分布式缓存与数据一致性保障
后端
用户790349033711 小时前
springboot集成redisson实现redis分布式锁
后端
陈随易1 小时前
程序员的新玩具,MoonBit(月兔)编程语言科普
前端·后端·程序员
老纪的技术唠嗑局1 小时前
单机分布式一体化数据库的架构设计与优化
数据库·分布式