八股已死、场景当立(场景篇-分库分表篇)

     废话不多说，今天更新场景篇-分库分表的知识点，做好了开始发车喽！

 一、场景篇-分库分表

1、Q:分库分表的核心概念及其解决什么问题?

   A:分库分表是解决数据库性能瓶颈的常用方案，包括：

分库：将数据按业务或功能拆分到多个数据库实例，降低单库压力，提高并发能力。分表：将单表数据按规则拆分到多个子表，解决单表数据量过大导致的查询性能下降问题。
核心目标是提升系统吞吐量、降低延迟，并支持水平扩展。

2、Q:  水平拆分与垂直拆分的区别及适用场景？

A:水平拆分解决数据量问题，垂直拆分解决业务耦合问题:

水平拆分：按数据行拆分（如按用户ID哈希），适合单表数据量大的场景（如订单表）。垂直拆分：按字段拆分（如将常用字段与冷字段分离），适合字段多、访问模式差异大的

3、Q: 如何设计分库分表的路由规则？以订单表为例说明？

A：常用路由规则：

哈希取模：
order_id % 分表数，均匀分布数据但不易扩容。范围分片：按时间或ID范围分片（如按月分表），易扩容但可能数据倾斜。复合路由：先按业务分库，再按哈希分表（如按用户ID分库，订单ID分表）。

4、Q: 分库分表后全局唯一ID如何生成？

A：推荐雪花算法，避免ID冲突且保持时序。

雪花算法（Snowflake）‍：64位ID（时间戳+机器ID+序列号），高性能且有序。数据库自增ID+步长：不同库设置不同自增步长，需维护步长配置。UUID：简单但无序，影响索引效率，不推荐为主键。

5、Q:分库分表后如何实现跨分片查询？

A：答案如下:

广播表：将小表（如配置表）复制到所有分库，避免跨库关联。冗余字段：在分片表中冗余关联表字段（如订单表冗余用户名称）。中间件聚合：通过ShardingSphere等中间件执行多库查询并聚合结果。
复杂查询需业务层避免或通过ES同步数据辅助查询。

6、Q:如何平滑迁移单表到分库分表？

A：双写迁移方案：

上线双写逻辑：所有写操作同时写入老表和分库分表新集群。数据同步：通过工具增量同步老数据到新集群，根据时间戳去重。校验数据一致性后，逐步将读请求切到新集群。下线老表写操作，完成迁移。

     此方案无需停机，保证数据一致性。

7、Q:分库分表后如何扩容？从3库12表扩到6库24表？

A：扩容步骤：

准备新库新表，并修改中间件配置支持新分片。数据迁移：将原有分片数据按新路由规则重新分布（如
order_id % 24）。双写期间，新旧集群同时写入，确保数据同步。逐步切流读请求，验证无误后下线旧分片。

     推荐初期设计多分片（如32库1024表），通过增加物理库扩容无需改路由。

8、Q:ShardingSphere如何实现分库分表？编写配置示例

A：Spring Boot + ShardingSphere配置（以订单表为例）：

spring:
  shardingsphere:
    datasource:
      names: ds0, ds1
      ds0: # 数据源配置
      ds1:
    rules:
      sharding:
        tables:
          order:
            actual-data-nodes: ds$->{0..1}.order_$->{0..3} # 2库4表
            key-generator: # 雪花算法生成ID
              column: order_id
              type: SNOWFLAKE
            database-strategy:
              standard:
                sharding-column: user_id
                algorithm-expression: ds$->{user_id % 2}
            table-strategy:
              standard:
                sharding-column: order_id
                algorithm-expression: order_$->{order_id % 4}

需引入
shardingsphere-jdbc-core依赖。

9、Q:分库分表后的常见问题及解决方案？

A：答案如下：

跨库事务：使用Seata等分布式事务框架，或最终一致性方案（如本地消息表）。分页查询：中间件聚合（性能低），或按分片查询后业务层排序分页。全局索引：通过同步数据到ES/ClickHouse辅助查询。数据倾斜：优化路由规则（如一致性哈希），或动态调整分片策略。

 10、Q: 如何监控分库分表系统的健康状态？        

A：答案如下:  

数据库监控：连接数、QPS、慢查询、磁盘空间（如Prometheus+Granafa）。中间件监控：ShardingSphere提供运行指标（如路由命中率、错误数）。业务日志：记录分片路由详情，便于排查数据分布问题。定期数据校验：对比分片数据与源表一致性。

11、Q:MyCat与ShardingSphere的优缺点对比？

A:推荐ShardingSphere用于Java技术栈项目：

12、Q:设计订单系统的分库分表方案（每日500万数据）?

A：方案设计：

分库策略：按用户ID哈希分库（如16个库），避免跨库查询。分表策略：按订单ID哈希分表（每库64表，共1024表），均匀分布数据。ID生成：雪花算法生成订单ID，内置时间戳便于按时间范围查询。冗余字段：订单表冗余用户ID、姓名，减少关联查询。迁移方案：双写迁移，同步工具增量同步历史数据。扩容准备：初期预留分片（如32库1024表），通过增加物理机线性扩展。

二、结语

这是一个系列专栏，场景题分库分表篇就写到这里，有需要的可以关注一下，下期更新场景题-分布式事务篇了！