分库分表需围绕数据访问模式精准解耦，核心是让查询落在单物理库表以避免跨节点操作；选高基数、高频等值字段作分片键，匹配哈希、时间或组合策略，并借助ShardingSphere等中间件实现路由与治理。
分库分表不是“一拆了之”，而是围绕数据访问模式做精准解耦。核心目标是让每次查询尽可能落在单个物理库表上，避免跨节点扫描、归并和排序——这才是提升查询性能的底层逻辑。
选对分片键，让高频查询直击目标
分片键（Sharding Key）决定数据怎么分，也决定查询怎么路由。选错就等于给查询加锁。
-
优先选高频等值查询字段：比如用户中心场景中，
user_id几乎所有接口都带，天然适合作为分片键；而用phone分片，查手机号快，但按昵称或邮箱查就得广播到所有分片 - 必须高基数、分布均匀：避免用状态码（如 status=0/1）、性别等低基数字段，否则出现“10万条数据全挤在2张表里”的热点问题
- 尽量不更新：一旦分片键变更（如用户迁籍），就得跨库迁移数据，运维成本极高
匹配业务场景，用对分片策略
没有银弹策略，只有合适策略：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
哈希取模（推荐用于用户/订单类主表）：如
user_id % 16→ 拆16张表。数据均匀，写入和点查极快；缺点是不支持BETWEEN或LIKE范围查询 -
时间范围分片（适合日志、流水、监控类表）：按月/按天建表，如
order_202607、order_202608。范围查询高效，冷热分离自然；但需预估容量，新月份要提前建表 -
组合分片（解决多维查询）：例如先按
tenant_id分库（租户隔离），再按user_id分表（库内均衡）。需中间件支持多分片键，如 ShardingSphere
借助成熟中间件，把路由逻辑收口
硬编码分片逻辑会污染业务，且难以统一治理。推荐采用轻量级 SDK 方式集成：
立即学习“Java免费学习笔记（深入）”；
- ShardingSphere-JDBC：以 Jar 包形式嵌入应用，兼容 MyBatis/JPA，SQL 解析+路由+归并在 JVM 内完成，无额外代理节点开销
-
配置即生效：YAML 中定义分片规则，比如指定
t_order表按order_id取模分 8 表，框架自动改写 SQL 并合并结果 - 避免“假分片”：确保所有涉及该表的 SQL 都带上分片键条件。没带？默认广播到全部分片——性能反而更差
配套必须跟上，否则性能反被拖累
分库分表只是架构一环，单点优化无效：
- 全局主键不能用自增ID：改用雪花算法（Snowflake）或分布式号段（如 Leaf），保证唯一且趋势递增，利于索引
-
禁止跨分片 JOIN 和深度分页：JOIN 改为应用层两次查询 + 内存关联；分页用“游标分页”（如
WHERE id > last_id LIMIT 20），避开OFFSET扫描 - 冷热分离 + 缓存前置：高频访问字段（如用户昵称、头像）用 Caffeine + Redis 多级缓存；历史归档数据可移出分片体系，降低主库压力
