分库分表的常用中间件有哪些？有哪些问题中间件无法提供帮助、只能改写业务代码的场景？使用了什么中间件？分库分表的实现场景和方式有哪些？分表之后，要查询两个表的数据要怎么查？分库分表的优缺点是什么？分库分表业界有哪些替代方案？（提示：分布式文件系统，因为分库分表会出现降低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><参考回答：></code></span>  分库分表后、跨节点 JOIN 查询会带来性能问题。 为了解决这个问题主要有以下几种方案：  1. 全局表： 如果是一些数据量小、变动不频繁的基础数据（比如权限表、配置表、商品分类表）可以将它们复制到每个数据库节点。 这样查询时可以直接在本地 JOIN、避免跨库。 但需要保证全局表的数据同步。  2. 冗余字段： 如果经常需要 JOIN 某些字段、可以将这些字段冗余存储到需要查询的表中。 比如在订单表中冗余存储用户的姓名和地址。 这样查询订单信息时、就不用 JOIN 用户表了。 但需要保证冗余字段的数据一致性。  3. ER 分片： 如果表之间存在很强的关联关系、比如订单表和订单详情表、可以按照相同的规则进行分片、保证它们在同一个数据库节点上。 这样就可以避免跨库 JOIN。（ER: 例如将订单表 和订单详情表按照 订单ID进行分片）使用一致性哈希算法、将 订单ID映射到不同的数据库节点上。关键： 保证具有相同 订单ID 的订单表记录和订单详情表记录、始终被分配到同一个数据库节点上。)<strong>面试官：非分片键的字段如何查询问题</strong><span> <code><参考回答：></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><参考回答：></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><参考回答：></code></span>1.如果 对 ID 的有序性有要求、且需要高性能的 ID 生成服务、我会优先选择雪花或者 Leaf-snowflake 。 雪花的优点是生成速度快、ID 趋势递增、有利于数据库索引的性能优化。Leaf-snowflake 在雪花的基础上、对时钟回拨问题进行了优化2.如果 对 ID 的有序性没有要求、且可以容忍一定的存储空间浪费、我会选择 UUID。 优点是本地生成、不需要依赖外部服务、生成速度快。3.如果 业务规模较大、对 ID 的全局唯一性、高性能和可扩展性有较高要求、我会选择构建一个专门的分布式 ID 生成服、例如使用 Leaf-segment 算法。 的优点是统一管理、方便维护和扩展、可以根据业务需求定制 ID 生成规则。后面再更新一下CSDN和一个语雀链接大家copy内容背诵就好了在我看来这个就是点到为止说出自己能知道多少就说多少 不要一点不知道 说多少都是缘分而且我觉得面试官自己也没做过分库分表具体的技术深度大家看看别的