分库分表
💡 一、为什么需要分库分表（动因）
核心目标：解决单库单表性能瓶颈。
数据量大 → 单表数据超千万行，查询慢、索引失效
并发高 → 单库连接数/事务冲突瓶颈
运维难 → 备份、迁移、恢复时间长
可用性差 → 单点故障风险高，难以扩展
✅ 示例句式：
随着业务发展，单表数据量过大或请求并发过高，数据库响应延迟明显，单库承压，因此需要通过分库分表来提升系统的吞吐能力与可用性。
🧩 二、分库分表的方式与策略
1. 拆分方式
垂直拆分（按业务模块拆库）：如用户、订单、商品拆成不同库
水平拆分（按数据范围拆表）：如
user_id% N 拆成 user_0, user_1…
2. 分片策略（Sharding Key）
范围分片（如：按时间、ID区间）
哈希分片（如：user_id % N）
标签分片（如：地区、商户ID）
✅ 示例句式：
水平拆分时我们通常选取业务查询最频繁的字段作为分片键，比如 user_id，使用 hash 或 range 分片以保证数据均衡与高可用。
⚙️ 三、常见技术实现方式
1. 自研方案
- 在 DAO 层封装路由逻辑，结合 ThreadLocal 或 AOP 实现数据源动态切换
- 灵活但维护成本高，适合中小型项目
2. 中间件方案（主流）
ShardingSphere-JDBC：支持分库分表、读写分离、柔性事务
MyCat：基于代理的分布式数据库中间件
TDDL：阿里内部方案
Vitess、PolarDB-X、OceanBase：云原生一体化解决方案
✅ 示例句式：
我们团队使用 ShardingSphere-JDBC 实现分库分表，通过配置 sharding rule 动态路由数据源，配合读写分离有效降低主库压力。
🔄 四、分布式事务与一致性问题
分片后事务可能涉及多个库，难以使用本地事务
解决方案：
强一致性：使用 XA 两阶段提交（开销大）
最终一致性：TCC、SAGA、消息补偿机制
避开事务：通过业务逻辑控制，将操作限制在单分片内
✅ 示例句式：
我们尽量通过业务分片控制事务边界落在同一个库上，如果无法避免跨库，则使用 TCC 模式实现柔性事务控制。
📈 五、扩容与维护
扩容：如原先 4 分片扩到 8 分片 → 面临数据迁移、路由规则变更
迁移策略：双写 + 验证 + 切换（或使用工具如 DataX、Canal）
监控点：热点分布、分片倾斜、主从同步延迟、慢 SQL
✅ 示例句式：
在分片扩容时，我们采用“新旧双写+数据比对+流量切换”策略，确保数据一致性和用户无感知迁移。
🧠 六、项目实战加分项（如有）
如果你曾实际在项目中用过分库分表，建议：
简要描述场景、数据量、采用的中间件和策略
强调你解决的关键问题，如：分片键选择、事务方案、查询优化
✅ 示例句式：
在智慧教育平台项目中，因题库表数据超千万，查询频繁，我们使用 ShardingSphere 做水平分表，按
question_id取模分为 8 表，并使用缓存+预查询优化了分页性能。
