分库分表常见问题参考答案（收录25年至今的牛客面经）

分库分表的常用中间件有哪些？
有哪些问题中间件无法提供帮助、只能改写业务代码的场景？
使用了什么中间件？
分库分表的实现场景和方式有哪些？
分表之后，要查询两个表的数据要怎么查？
分库分表的优缺点是什么？
分库分表业界有哪些替代方案？（提示：分布式文件系统，因为分库分表会出现降低QPS，比如range查询失效）
为什么做了分库分表后分页比较困难了？
如果10亿数据要分表，要怎么分？业务怎么切？
分库分表怎么保证数据一致性？
选的什么分片键？什么分片算法？
分库分表后的分布式ID怎么做？
（2025年目前为止的牛客面经关于分库分表的问题收集）


总结：
分布式事务一致性问题
跨节点关联查询JOIN问题（解决方案：1.全局表 2.冗余字段 3.建立1：1的ER实体关系分片）
非分片键的查询问题（1.创建映射表 2.  前缀分片法  3.使用ES搜索引擎（最后才说要抬高立意）
全局分布式ID问题（1.UUID 2.雪花算法 3.mysql/Redis 4.美团Leaf（1.Leaf-segment 2.Leaf-snowflake）
跨库跨节点分页查询问题（不会）

与朋友合作的开源Go KV项目
路过可以的话帮我们点个star✨🌟
https://github.com/FinnTew/FincasKV

参考面试回答：（吟唱）
<strong>面试官：分库分表后、如何解决跨节点JOIN查询问题</strong>
<span> <code>&amp;lt;参考回答：&amp;gt;</code></span>
  分库分表后、跨节点 JOIN 查询会带来性能问题。 为了解决这个问题主要有以下几种方案：
  1. 全局表： 如果是一些数据量小、变动不频繁的基础数据（比如权限表、配置表、商品分类表）可以将它们复制到每个数据库节点。 这样查询时可以直接在本地 JOIN、避免跨库。 但需要保证全局表的数据同步。
  2. 冗余字段： 如果经常需要 JOIN 某些字段、可以将这些字段冗余存储到需要查询的表中。 比如在订单表中冗余存储用户的姓名和地址。 这样查询订单信息时、就不用 JOIN 用户表了。 但需要保证冗余字段的数据一致性。
  3. ER 分片： 如果表之间存在很强的关联关系、比如订单表和订单详情表、可以按照相同的规则进行分片、保证它们在同一个数据库节点上。 这样就可以避免跨库 JOIN。
（ER: 例如将订单表 和订单详情表按照 订单ID进行分片）
使用一致性哈希算法、将 订单ID映射到不同的数据库节点上。
关键： 保证具有相同 订单ID 的订单表记录和订单详情表记录、始终被分配到同一个数据库节点上。)


<strong>面试官：非分片键的字段如何查询问题</strong>
<span> <code>&amp;lt;参考回答：&amp;gt;</code></span>
问题背景：我们选择分片键的时候都是选用查询场景最多的字段来做分片键、但是可能需要查询非分片键下的所有所有数据。例如电商用(订单ID) 做分片但是我们可能会查询订单类型、这些数据可能被分到了不同的库、我们需要聚合所有库的查询、然后返回给前端。导致效率低下
回答参考方案：
<strong>1.关系映射表：映射关系表就是存储待查询字段和分片键映射关系的一张表、当要使用非分片键查询的时候、先到映射关系表中查询字段所对应的所有分片键、再根据分片键查询所有信息。</strong>
（例如创建一个额外的映射表Map、包含 订单ID 和 订单类型 的对应关系。当插入新订单时、同时更新这个映射表。查询时先查映射表获取所有的 订单ID、再根据 订单ID列表查询分片表。总结一下就是用映射去查询我们就可以得到了 缺点是要维护新的Map 适用于对实时性要求不高的情况）
<strong>2.  前缀分片法：利用（订单ID）的某些特征来决定数据存储在哪个分片上，并将这个嵌入到主键中。 这样既可以通过主键进行分片、又可以通过UID进行分片。</strong>
（例如在生成 订单时，嵌入 用户ID 的某些特征 例如 用户ID的最后一位。然后使用包含这个 订单ID进行分片。这样既可以通过 订单分片，也可以通过 用户ID的特征进行路由。优点不需要额外的存储空间 缺点是可能会产生如果 用户ID分布不均匀、可能会导致数据倾斜）
<strong>3.ES: 将所有订单数据同步到ES中、利用 ES 的全文检索和聚合分析能力、进行多条件查询</strong>


<strong>面试官：分库分表后的分布式ID怎么做？</strong>
<span> <code>&amp;lt;参考回答：&amp;gt;</code></span>
问题背景：分库分表后需要一个唯一ID来标识一条数据或消息。
回答参考方案：说一下各大方案及优缺点就行。
1. UUID（优点本地生成、缺点是16字节128位存储成本高以及会产生页分裂问题
2.雪花算法（优点生成性能高、可以根据业务特征分配Bit位、缺点是依赖强时间回钟）
3.MySQL自增主键和Redis的Incr命令（不做探讨）
3. 分布式ID生成服务、如美团的leaf算法（Leaf-segment和Leaf-snowflake）
大家这里可以去看美团技术文章 这里引导一下思路就好


<strong>面试官：如果要你选择一个分布式ID生成方案你会选什么</strong>
<span> <code>&amp;lt;参考回答：&amp;gt;</code></span>
1.如果 对 ID 的有序性有要求、且需要高性能的 ID 生成服务、我会优先选择雪花或者 Leaf-snowflake 。 雪花的优点是生成速度快、ID 趋势递增、有利于数据库索引的性能优化。Leaf-snowflake 在雪花的基础上、对时钟回拨问题进行了优化
2.如果 对 ID 的有序性没有要求、且可以容忍一定的存储空间浪费、我会选择 UUID。 优点是本地生成、不需要依赖外部服务、生成速度快。
3.如果 业务规模较大、对 ID 的全局唯一性、高性能和可扩展性有较高要求、我会选择构建一个专门的分布式 ID 生成服、例如使用 Leaf-segment 算法。 的优点是统一管理、方便维护和扩展、可以根据业务需求定制 ID 生成规则。

更新一下CSDN： https://blog.csdn.net/wy990880?type=blog
大家copy内容背诵就好了
在我看来这个就是点到为止说出自己能知道多少就说多少 不要一点不知道 说多少都是缘分
而且我觉得面试官自己也没做过分库分表
具体的技术深度大家看看别的