分库分表之实战-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个库：ds0、ds1）
分表策略 ：按id取模（每个库分2张表：t0、t1）
完整表名格式：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_t0、ds1.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中新增测试函数（分表键id用IN查询）：

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未指定，需扫描所有分库的t0和t1
实际执行：ds0.t0、ds0.t1、ds1.t0、ds1.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_id和id，无法定位分库分表
实际执行：查询所有4张表（ds0.t0、ds0.t1、ds1.t0、ds1.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→t0、1942559779014868995→t1，但无分库键user_id
实际执行：删除ds0.t0、ds0.t1、ds1.t0、ds1.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的路由逻辑基于「分片键提取→分片算法计算→目标库表定位」三步：

提取分片键 ：从SQL的WHERE条件中解析分库键（如user_id）和分表键（如order_id）
计算分片：调用配置的分片算法（如取模、哈希），得到目标库索引和表索引
生成路由：若有完整分片键，生成「标准路由」；若缺失，生成「全库表路由」

五、最佳实践与避坑指南

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_id或order_id），同时结合监控工具（如Sharding-Jdbc的SQL日志）跟踪路由情况，及时优化不合理的操作。

觉得有用请点赞收藏！

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

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

本文章目录

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

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

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

1. 有分片键的查询（标准路由）

（1）= 条件查询（单分片键）

（2）IN 条件查询（多分片键）

2. 无分片键的查询（全库表路由）

三、删除操作实战

1. 有分片键的删除（标准路由）

（1）= 条件删除

（2）IN 条件删除

2. 无分片键的删除（全库表路由）

四、路由原理：Sharding-Jdbc如何决定路由规则？

五、最佳实践与避坑指南

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

2. 谨慎使用IN条件

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

4. 结合索引优化查询

5. 注意事务一致性

六、总结

2. 谨慎使用`IN`条件