# 1. 分库分表与 Spring Data 的 @Table/@ShardingSphere 整合 A @Table 声明逻辑表名，ShardingSphere 按分片规则改写并根据分片键路由到物理表 ✓ 正确答案 B 分库分表后 @Table 注解失效 C ShardingSphere 与 Spring Data 无法共存 D @Table 必须声明物理表名（如 order_0），否则无法分片
# 2. 分库分表后的分布式事务（Seata） A AT 模式通过 undo log 自动补偿回滚，侵入小；TCC 需业务实现 Try/Confirm/Cancel，性能好但侵入强 ✓ 正确答案 B Seata 只有 AT 一种模式 C 分库分表后无需分布式事务，单库事务即可 D Seata 只能用于单体应用，无法用于微服务
# 3. ShardingSphere 的 broadcast 表（字典表）应用 A 广播表只存在于一个分片库，其他分片库不存储 B 广播表在每个分片库都有完整副本，写操作广播到所有库，读操作从任意库读取，适合字典表等全局基础数据 ✓ 正确答案 C 广播表不能执行写操作 D 广播表用于大数据量大并发场景
# 4. ShardingSphere 的分片策略（hash/range）与绑定表/广播表的应用场景？ A 绑定表用于跨分片 join 优化，与分片键无关 B hash 分片天然支持范围查询 C hash 分片数据均匀但范围查询需聚合，range 分片支持范围查询但可能倾斜；绑定表保证同分片 join，广播表用于全局字典 ✓ 正确答案 D 广播表用于大数据量表
# 5. 查询未携带分片键时的路由策略与业务约束（禁止全库扫描、路由提示与索引兜底） A ShardingSphere 会自动给出正确分片，无需处理 B 未携带分片键默认全库扫描，性能差，应通过业务约束强制带分片键、用 hint 路由或索引表兜底规避 ✓ 正确答案 C 全库扫描性能与单分片查询相同 D 未携带分片键的查询会被直接拒绝，不会执行
# 6. 分库分表后的全局 ID、分布式事务与跨库查询（聚合/Join）如何降级处理？ A 全局 ID 用数据库自增即可保证唯一 B 跨库聚合/Join 可通过字段冗余、宽表、应用层聚合或 ES 降级实现，分布式事务可退化为最终一致 ✓ 正确答案 C 分库分表后仍可直接执行跨库 Join D 分布式事务只支持强一致，无法降级
# 7. ShardingSphere 的 hint 强制路由 A hint 只在 SQL 含分片键时生效 B hint 通过 HintManager 在代码中显式指定路由目标，适用于 SQL 无法推导分片键的场景 ✓ 正确答案 C hint 路由会自动持久化，无需手动清理 D hint 只能用于读操作，不能用于写操作
# 8. ShardingSphere-JDBC 的 SQL 改写与路由 A 处理流程是解析、路由、改写、执行、归并，改写把逻辑表名换为物理表名并调整分页聚合 ✓ 正确答案 B 结果归并只做简单拼接，不处理排序分页 C 它只做路由，不改写 SQL D 它通过修改应用代码的 SQL 来实现分片
# 9. 分库分表扩容的数据迁移（双写/停机/平滑）方案如何选择？ A 停机迁移无需停机，适合所有场景 B 平滑迁移无需任何数据同步 C 双写迁移最简单，无任何风险 D 双写迁移无需停机但需处理幂等与补偿，平滑迁移对业务影响最小但实现最复杂，需按停机容忍度选型 ✓ 正确答案
# 10. 分库分表后的全局唯一 ID 方案，雪花算法、号段模式与 UUID 的并发/排序特性对比如何？ A 雪花算法与号段模式趋势递增、利于聚簇索引，UUID 无序且过长会降低索引插入性能 ✓ 正确答案 B UUID 有序且利于索引，是分库分表主键的最优选择 C 雪花算法不依赖任何时钟 D 号段模式不依赖数据库
# 11. 分库分表后的跨分片查询，全局聚合、分页排序与分布式事务（XA/柔性事务）如何处理？ A 跨分片聚合与分页需分片执行+归并，深分页代价高应规避；分布式事务按一致性要求选 XA 或柔性事务 ✓ 正确答案 B 跨分片分页可直接各分片取 LIMIT 合并，结果必然全局正确 C XA 分布式事务性能最好，适合所有场景 D 分库分表后无需考虑分布式事务
# 12. 数据倾斜与热点分片（订单尾号不均匀）的识别与治理（预分片、热点扩容、读写分离） A 数据倾斜只影响查询，不影响写入 B 预分片越多越好，无需考虑扩容 C 读写分离不能缓解热点分片压力 D 可通过监控分片数据量与 QPS 对比识别倾斜，用预分片规划、热点扩容、读写分离及加盐打散治理 ✓ 正确答案
# 13. 读写分离与分库分表叠加时的路由优先级与主从延迟处理 A 先按分片键确定分片，再在该分片内按读写分离选主从；主从延迟下强一致读走主库 ✓ 正确答案 B 所有读都走主库可完全避免延迟问题 C 读写分离与分片叠加后主从延迟消失 D 路由优先级是先选主从，再分片
# 14. ShardingSphere/MyCat 的接入方式，Proxy 与 JDBC 两种模式的差异与 Spring 集成要点如何？ A Proxy 模式性能一定优于 JDBC 模式 B JDBC 模式需要独立部署中间件服务器 C JDBC 模式以内嵌 DataSource 代理接入，无需额外中间件；Proxy 模式独立部署，对应用透明，方便多语言与集中治理 ✓ 正确答案 D 两种模式都需要修改应用代码
# 15. 分片键的选择与路由，范围分片/哈希分片/一致性哈希的适用场景如何？ A 范围分片数据一定均匀分布 B 分片键应选择低基数、分布集中的字段 C 一致性哈希实现最简单，无需处理数据迁移 D 哈希分片数据均匀但扩容时需大量重分布，一致性哈希扩容只需迁移环上少量数据 ✓ 正确答案
# 16. 分库分表的扩容迁移，双写、停机与在线迁移如何取舍？ A 停机迁移适合不允许停机的业务 B 双写迁移完全不需要数据同步 C 在线迁移无需任何工具支持 D 停机迁移简单但需停服，双写无需停机但需处理幂等补偿，在线迁移最平滑但实现最复杂 ✓ 正确答案
# 17. 分库分表后跨分片 JOIN 的替代，字段冗余、宽表、应用层聚合与 ES 的取舍 A 字段冗余与宽表避免 Join、应用层聚合在内存 Join、ES 承载复杂查询，按复杂度与一致性要求取舍 ✓ 正确答案 B ES 引入后无需处理数据同步延迟 C 宽表适合频繁变化的数据 D 字段冗余无需处理冗余数据的一致性
