NewSQL（TiDB & OceanBase）知识体系

本文全方位、结构化拆解NewSQL两大标杆产品TiDB与OceanBase的核心知识体系，覆盖核心设计理念、分布式架构、底层核心原理、分布式事务实现、HTAP能力五大核心模块，同时补充核心能力对标与行业落地范式，形成完整的知识闭环。

一、NewSQL 基础定位与核心设计范式

1.1 核心定义与解决的核心痛点

NewSQL是兼具传统关系型数据库的ACID语义、完整SQL兼容性，与NoSQL的分布式弹性扩展、高可用能力的新型分布式关系型数据库，核心解决两大行业痛点：

1. 单机关系型数据库的容量、性能瓶颈，无法应对海量数据与高并发场景；
2. NoSQL数据库放弃SQL支持、事务强一致性与关系模型，无法适配核心交易业务与复杂查询需求。

1.2 NewSQL 核心设计范式（两大产品通用底层逻辑）

二、TiDB 核心知识体系

2.1 核心设计理念与产品定位

TiDB是PingCAP研发的开源分布式NewSQL数据库，核心设计理念为MySQL完全兼容、计算存储分离、原生分布式、HTAP一体化，主打互联网、企业级业务的海量数据高并发场景，实现业务从MySQL的无缝迁移，同时解决单机容量瓶颈与实时分析需求。

2.2 分布式架构详解

TiDB采用分层解耦的计算-存储分离架构，核心分为四大核心组件，所有组件均支持水平扩展，组件间通过gRPC通信：

客户端 → TiDB Server（计算层） → PD Server（调度层）
                          ↓
                TiKV Server（行存TP层） ↔ TiFlash Server（列存AP层）

1. 计算层：TiDB Server

   • 无状态节点，不存储任何数据，仅负责SQL计算，可无限水平扩展；
   • 核心职责：MySQL协议接入、SQL解析、语义校验、基于代价的优化器（CBO）、分布式执行计划生成、会话管理、权限控制；
   • 核心能力：支持MPP大规模并行执行框架，可将计算任务下推到存储层，适配复杂OLAP查询。

2. 调度层：PD Server（Placement Driver）

   • 集群的“大脑”，基于Raft协议实现多副本高可用（通常3节点部署），是集群唯一的全局信息中心；
   • 核心职责：全局单调递增TSO时间戳分配（分布式事务核心依赖）、集群元数据管理、Region分片调度与负载均衡、副本拓扑管理、容灾策略执行、集群状态监控。

3. 行存存储层（OLTP核心）：TiKV Server

   • 分布式强一致KV存储引擎，基于Raft共识协议实现多副本强一致，是TiDB的行存数据底座；
   • 核心职责：数据持久化存储、MVCC多版本控制、分布式事务底层支持、行存数据读写优化；
   • 核心数据单元：Region（默认96MB），是数据分片、副本管理、调度的最小单元，每个Region维护一段连续的Key范围，自动分裂、合并与迁移，对业务完全透明。

4. 列存HTAP层（OLAP核心）：TiFlash Server

   • 面向OLAP优化的列存存储引擎，是TiKV的Raft Learner副本，实现TP与AP的资源物理隔离；
   • 核心职责：行存数据实时转列存、高压缩比列存存储、向量化执行、MPP并行计算，支撑复杂聚合、关联分析等OLAP场景。

2.3 核心底层原理

1. 关系模型到KV模型的映射
   TiDB的核心创新是将关系模型无缝映射到KV存储，实现MySQL兼容的核心基础：

   • 表行数据映射：Key = tableID + rowID，Value = 行全列数据，实现行数据的快速点查；
   • 索引数据映射：Key = tableID + indexID + 索引列值，Value = rowID，兼容主键、二级索引、联合索引等MySQL全索引类型；
   • 优势：无需修改底层KV引擎，即可完整支持关系模型，实现与MySQL的语法、语义全兼容。

2. 数据分片与调度原理

   • 采用Range范围分片，而非Hash分片，天然适配范围查询、分页查询场景，避免热点数据扩散；
   • PD基于集群负载、节点容量、副本拓扑，自动执行Region的分裂、合并、迁移，实现全局负载均衡，全程对业务无感知。

3. 高可用与一致性原理

   • 每个Region默认3副本，跨节点/可用区部署，基于Raft协议实现强一致，仅当多数副本写入成功，才向客户端返回成功；
   • Raft Leader负责读写请求，Follower副本同步日志，Leader故障时，剩余副本自动秒级选主切换，RPO=0，RTO<30s。

4. MVCC多版本并发控制
   基于PD分配的TSO时间戳实现MVCC，每个Key的多个版本以时间戳标识，事务仅能读取小于自身start_ts的已提交版本，实现无锁快照读，避免读写阻塞，同时解决不可重复读与幻读问题。

2.4 分布式事务实现机制

TiDB基于Google Percolator分布式事务模型，实现跨节点、跨Region的强一致分布式事务，原生支持乐观事务与悲观事务双模型，默认采用悲观事务模型（与MySQL行为完全兼容）。

2.4.1 事务核心基础

• 全局唯一、单调递增的TSO时间戳（由PD统一分配），作为事务的版本号，实现全局快照隔离，保证分布式事务的一致性与有序性；
• 基于MVCC实现多版本控制，支持MySQL兼容的可重复读（RR，默认） 与读已提交（RC） 两种隔离级别，其中RR级别基于全局快照隔离，彻底解决幻读问题（与MySQL基于间隙锁的RR实现不同）。

2.4.2 核心事务模型实现

1. 悲观事务模型（默认）

专为高并发、高冲突的OLTP场景设计，完全兼容MySQL的事务语义，解决乐观事务的提交冲突问题：

1. 事务开启，从PD获取start_ts作为事务的快照版本号；
2. 执行DML语句时，立即对目标行在TiKV上加悲观行锁，阻塞其他事务对该行的修改，锁通过TTL机制维护有效期，避免死锁；
3. 所有语句执行完成，事务提交，进入Percolator两阶段提交（2PC）流程；
4. 提交完成，释放所有锁，向客户端返回提交成功。

2. 乐观事务模型

适用于读多写少、低冲突场景，事务执行阶段不加锁，仅在提交时校验冲突：

1. 事务开启，从PD获取start_ts，所有读取操作基于该快照版本；
2. 事务执行阶段，所有修改缓存在TiDB Server本地，不写入TiKV，不加锁；
3. 事务提交，进入Percolator 2PC流程：
   • Prewrite阶段：TiDB选定一个Primary Key（主键），其余修改的Key为Secondary Key；对所有Key写入Prewrite记录与锁，校验版本冲突，若存在冲突则事务回滚；所有Key Prewrite成功，方可进入提交阶段。
   • Commit阶段：从PD获取commit_ts，先提交Primary Key，写入Commit记录并释放锁；Primary Key提交成功，事务即全局成功，后续异步提交所有Secondary Key，完成事务全流程。

2.4.3 事务核心优化

• 异步提交优化：Secondary Key异步提交，降低事务提交延迟；
• 1PC优化：单Region事务跳过2PC流程，直接提交，大幅提升性能；
• 组提交优化：多个事务的日志合并写入，减少磁盘IO，提升高并发下的TPS。

2.5 HTAP 能力实现原理

TiDB采用行存+列存双引擎、数据实时同步、资源物理隔离的HTAP架构，是业界首个实现“一份数据、两种存储、TP/AP隔离”的开源HTAP数据库，核心实现如下：

1. 数据一致性与实时同步
   TiFlash作为TiKV Region的Raft Learner副本，仅同步Raft日志、不参与Raft投票与选主，完全不影响TiKV的OLTP性能；行存数据从TiKV实时同步到TiFlash，自动转为列存格式，同步延迟毫秒级，通过TSO时间戳保证全局快照一致性，实现OLTP写入的数据可实时被OLAP查询。

2. 存储与执行引擎优化

   • 列存引擎：TiFlash采用面向OLAP优化的列存格式，高压缩比（可达10:1），支持向量化执行，大幅提升聚合、关联、排序等复杂查询的性能；
   • 智能路由：TiDB的CBO优化器自动识别查询类型，OLTP点查、短查询自动路由到TiKV行存引擎，OLAP复杂聚合查询自动路由到TiFlash列存引擎，对业务完全透明；
   • MPP并行执行：TiFlash支持大规模并行计算，将复杂查询拆分为多个子任务，分发到多个TiFlash节点并行执行，最终汇总结果，可支撑TPC-H级别的复杂分析场景。

3. 资源隔离保障
   TiKV与TiFlash部署在独立的物理节点，CPU、内存、磁盘IO、网络资源完全物理隔离，OLAP查询无论负载多高，都不会抢占OLTP业务的资源，彻底解决传统架构中TP与AP的资源抢占问题。

三、OceanBase 核心知识体系

3.1 核心设计理念与产品定位

OceanBase是蚂蚁集团研发的原生分布式NewSQL数据库，核心设计理念为计算存储一体化、原生HTAP融合、金融级高可用、MySQL/Oracle双兼容，主打金融、银行、证券等核心交易场景，经过支付宝双11超大规模流量验证，可支撑核心系统的全量替换，同时兼顾海量数据实时分析需求。

3.2 分布式架构详解

OceanBase采用计算存储一体化的Share-Nothing对等架构，无专门的计算/存储节点之分，所有节点功能对等，核心分为三大组件，原生支持多租户架构，实现资源的精细化隔离与管控：

客户端 → OBProxy（接入层） → OBServer（计算存储一体化节点）
                                    ↓
                          RootService（总控服务，内置在OBServer）

1. 接入层：OBProxy

   • 无状态反向代理节点，支持水平扩展，是客户端访问集群的统一入口；
   • 核心职责：MySQL/Oracle协议兼容、SQL路由、读写分离、负载均衡、故障转移、连接池管理、权限校验；
   • 核心能力：可感知集群分区拓扑与副本状态，将SQL精准路由到对应Leader副本所在的OBServer节点，减少跨节点通信，大幅降低访问延迟。

2. 总控服务：RootService（RS）

   • 集群的“大脑”，基于Paxos协议实现多副本高可用，内置在OBServer节点中，无需独立部署；
   • 核心职责：全局GTS时间戳分配、集群元数据管理、分区调度与负载均衡、副本拓扑管理、故障自动切换、租户资源管理、集群容灾策略执行。

3. 核心数据节点：OBServer

   • 计算存储一体化对等节点，所有节点功能完全一致，既负责SQL计算，又负责数据存储，支持水平扩展；
   • 核心职责：SQL引擎执行、事务处理、数据存储与读写、副本同步、Paxos协议实现；
   • 核心特性：原生支持多租户，一个OBServer节点可承载多个租户的资源，租户之间CPU、内存、IO完全隔离，每个租户可独立选择MySQL/Oracle兼容模式，相当于一个独立的数据库实例。

4. 核心数据单元

   • 分区（Partition）：数据分片的最小单元，支持Range、Hash、List、复合分片模式，适配不同业务场景；
   • 副本：每个分区默认3副本，基于Paxos协议实现强一致，副本类型分为全功能副本（Leader/Follower，负责读写/同步）、日志副本、只读列存副本，支持灵活的容灾拓扑部署。

3.3 核心底层原理

1. 原生关系模型与存储引擎架构
   OceanBase无需将关系模型映射到KV存储，原生支持关系模型，底层采用基于LSM-Tree优化的基线+增量融合存储引擎，核心设计如下：

   • 数据组织：分为增量数据（MemTable，内存中的可写结构）与基线数据（SSTable，磁盘中的只读结构），写入操作仅追加到MemTable，无需原地修改，实现随机写转顺序写，大幅提升写入性能；
   • 自适应合并机制：独创的增量合并技术，替代传统LSM-Tree的Major Compaction，仅合并变更的宏块，大幅降低写放大与合并对业务的影响，支持业务高峰暂停合并，低峰期自适应执行；
   • 高压缩存储：支持列式编码、字典编码、RLE等多种压缩算法，平均压缩比可达5:1以上，远高于传统数据库，大幅降低海量数据的存储成本。

2. 数据分片与调度原理

   • 支持灵活的分片模式：Range分片适配范围查询，Hash分片适配高并发随机读写，List分片适配按地域/业务类型分片，复合分片适配复杂业务场景；
   • RootService基于集群负载、分区热度、节点容量，自动执行分区的迁移、分裂、合并，实现全局负载均衡，支持按租户、按表设置调度策略，精细化管控。

3. 高可用与容灾原理

   • 基于Paxos分布式共识协议，每个分区的多副本跨节点/可用区/城市部署，仅当多数副本写入成功，才向客户端返回成功，保证数据强一致；
   • 支持同城三中心、两地三中心、三地五中心等金融级容灾架构，Leader副本故障时，剩余副本自动秒级选主切换，RPO=0，RTO<8s，可实现城市级故障不影响业务可用性；
   • 原生支持主备集群、数据同步、备份恢复，满足金融监管的合规要求。

4. MVCC多版本并发控制
   基于全局GTS时间戳实现MVCC，每行数据维护多个版本，版本号以事务的提交时间戳标识，实现无锁快照读，读写互不阻塞，支持完整的四种事务隔离级别，适配Oracle/MySQL的不同语义。

3.4 分布式事务实现机制

OceanBase基于原生两阶段提交（2PC）+ 全局GTS时间戳 + Paxos共识协议实现分布式事务，主打悲观事务模型，原生适配金融级核心交易场景，实现跨节点、跨分区的ACID强一致保证，性能与可靠性经过超大规模验证。

3.4.1 事务核心基础

• 全局唯一、单调递增的GTS时间戳（由RootService统一分配），作为事务的全局版本号，实现全局快照隔离，保证分布式事务的有序性与一致性；
• 原生支持读未提交、读已提交（RC）、可重复读（RR）、串行化四种标准隔离级别，Oracle兼容模式默认RC，MySQL兼容模式默认RR，与商业数据库语义完全兼容，业务零改造迁移。

3.4.2 分布式事务核心实现

OceanBase的事务模型针对分布式场景做了极致优化，单分区事务自动优化为1PC提交，仅跨分区/跨节点的分布式事务执行完整的2PC流程，兼顾性能与一致性。

1. 事务核心流程

   1. 事务开启：OBProxy将请求路由到协调者OBServer（事务发起节点），从RootService获取start_scn（事务起始版本号）；
   2. 事务执行：执行DML语句，悲观模式下立即对目标行加行级锁，阻塞其他事务的修改，支持意向锁、行锁等待、死锁检测，与Oracle/MySQL语义完全兼容；
   3. 提交阶段：
      • 准备阶段（Prepare）：协调者向所有参与者（修改了数据的分区/OBServer）发送Prepare请求，参与者将事务日志通过Paxos同步到多数副本，持久化到磁盘，锁定资源，返回Prepare成功；若任意参与者Prepare失败，协调者发起全局回滚。
      • 提交阶段（Commit）：所有参与者Prepare成功，协调者向所有参与者发送Commit请求，参与者提交事务、释放锁、写入提交记录，返回Commit成功；协调者收到所有成功响应后，向客户端返回事务提交成功。

2. 事务核心优化

   • 1PC优化：单分区单机事务，直接跳过Prepare阶段，执行1PC提交，减少一半的网络交互与日志开销，绝大多数OLTP场景均可命中该优化，性能接近甚至超过单机数据库；
   • 组提交优化：多个事务的日志合并持久化，减少磁盘IO次数，大幅提升高并发下的TPS；
   • 只读事务优化：只读事务无需加锁、无需提交，直接基于快照读取，无任何额外开销；
   • 全局死锁检测：内置分布式死锁检测器，实时检测跨节点的死锁，自动回滚代价最小的事务，解决分布式场景的死锁问题；
   • 事务日志优化：事务日志基于Paxos同步，仅需多数副本持久化成功即可返回，兼顾性能与可靠性。

3.5 HTAP 能力实现原理

OceanBase采用原生行列融合一体化HTAP架构，是业界首个实现“一份数据、行列融合、TP/AP全场景支持”的分布式数据库，无需额外存储副本即可同时支撑OLTP与OLAP场景，最新4.x版本补充了专用列存副本，实现极致的HTAP能力。

1. 核心架构：行列融合存储引擎
   OceanBase的核心创新是原生的行列融合存储，无需维护两份独立的数据副本，一份数据同时适配TP与AP场景：

   • 基线数据采用宏块（2MB）组织，每个宏块内分为多个微块（16KB），微块内采用列式存储，宏块间保持行存的组织形式；
   • 优势：OLTP点查、更新操作可直接命中行级数据，性能与纯行存引擎一致；OLAP聚合、关联查询可直接读取列存数据，执行向量化计算，性能与纯列存引擎相当，同时避免了双副本的存储冗余与同步开销。

2. 专用列存副本与实时同步
   针对超大规模OLAP场景，OceanBase提供专用的静态列存副本，基于Paxos协议与行存副本实时同步，数据强一致，同步延迟毫秒级；列存副本可独立部署在专属节点，与OLTP行存副本实现物理资源隔离，OLAP查询不会影响OLTP业务的稳定性。

3. 执行引擎与智能优化

   • 双执行引擎：同时支持OLTP优化的火山模型，与OLAP优化的向量化执行、MPP大规模并行执行框架，可适配从点查到复杂分析的全场景SQL；
   • 智能CBO优化器：基于代价自动识别查询类型，OLTP短查询自动选择行存执行路径，OLAP复杂查询自动选择列存+向量化+MPP执行路径，自动路由到最优副本，对业务完全透明；
   • 计算下推：支持将过滤、聚合、关联等计算逻辑下推到存储层执行，减少数据传输，大幅提升查询性能。

4. 精细化资源隔离
   基于原生多租户架构，实现多层级的资源隔离：

   • 租户级隔离：OLTP与OLAP业务部署在独立租户，CPU、内存、IO、网络资源完全隔离，互不影响；
   • 资源池隔离：同一租户内，可将OLTP与OLAP业务分配到不同的资源池，绑定专属节点，实现物理隔离；
   • 查询管控：支持查询限流、并发控制、资源队列、执行超时管控，避免大查询占用过多资源，保障OLTP业务的稳定性。

四、TiDB vs OceanBase 核心能力对比表

五、NewSQL 核心技术共性与行业落地范式

5.1 两大产品核心技术共性

1. 分布式共识协议：均基于Raft/Paxos工业级共识协议，实现多副本数据强一致与高可用，是分布式架构的核心底座；
2. 全局时间戳机制：均通过全局统一的时间戳分配器（TSO/GTS），实现分布式事务的全局有序性与快照隔离，是分布式事务的核心基础；
3. MVCC多版本并发控制：均基于时间戳实现MVCC，解决读写阻塞问题，实现高并发下的事务隔离；
4. 两阶段提交（2PC）：均基于2PC实现跨节点分布式事务，同时针对单分区场景做1PC优化，兼顾一致性与性能；
5. 原生HTAP能力：均实现了TP与AP的一体化支持，避免ETL延迟与数据冗余，实现业务数据的实时分析；
6. 弹性水平扩展：均支持无共享架构的水平扩缩容，扩容对业务完全透明，可应对海量数据与流量的增长；
7. 在线DDL：均支持无锁在线DDL，表结构变更不锁表、不影响业务正常运行，解决传统数据库大表变更的痛点。

5.2 行业落地选型建议

1. 优先选择TiDB的场景

   • 业务基于MySQL开发，需要无缝迁移到分布式架构，零代码改造；
   • 互联网高并发OLTP场景，同时需要实时数据分析、报表、数仓能力；
   • 开源技术栈，需要活跃的社区支持、丰富的生态工具与云原生适配；
   • 业务快速迭代，需要灵活的扩缩容能力，降低运维复杂度。

2. 优先选择OceanBase的场景

   • 金融级核心交易系统，需要极致的高可用、容灾能力与数据可靠性；
   • 基于Oracle开发的核心业务，需要低成本、低风险的国产化替换；
   • 超大规模业务场景，需要极致的性能、高压缩比，降低硬件与存储成本；
   • 多业务系统整合，需要内核级多租户能力，实现资源隔离与统一运维。

《 TiDB & OceanBase 面试核心考点速记清单 》

这份清单严格贴合大厂后端开发、DBA、数据库研发岗面试高频考点，按分布式架构、分布式事务、HTAP核心三大必考模块划分，标注考点高频星级，答案精炼踩中得分点，可直接背诵。

一、分布式架构模块（面试开场必问，基础核心，★★★★★全覆盖）

（一）必背基础考点

1. 问：NewSQL的核心定义与解决的两大核心痛点？
   答：NewSQL是兼具传统关系型数据库ACID语义、完整SQL兼容性，与NoSQL分布式弹性扩展、高可用能力的新型分布式关系型数据库。
   核心解决痛点：① 单机关系型数据库的容量、性能瓶颈，无法适配海量高并发场景；② NoSQL放弃SQL、事务与关系模型，无法支撑核心交易与复杂查询。
   高频星级：★★★★★

2. 问：Share-Nothing分布式架构的核心优势？
   答：节点间无共享资源，完全对等/解耦；支持水平无限扩展，扩容对业务透明；无单点瓶颈，故障影响范围可控；天然适配多副本高可用与容灾部署。
   高频星级：★★★★★

（二）TiDB专属架构核心考点

1. 问：TiDB的四大核心组件及核心职责？
   答：TiDB采用计算-存储分离分层架构，四大组件均支持水平扩展：

   • TiDB Server（计算层）：无状态，MySQL协议接入、SQL解析优化、分布式执行计划生成，不存储数据；
   • PD Server（调度层）：集群大脑，Raft多副本高可用，核心负责全局TSO时间戳分配、元数据管理、Region分片调度与负载均衡；
   • TiKV Server（行存TP层）：分布式强一致KV存储，Raft多副本，是OLTP数据底座，数据分片最小单元为Region；
   • TiFlash Server（列存AP层）：TiKV的Raft Learner列存副本，负责OLAP复杂查询，实现HTAP资源隔离。
     高频星级：★★★★★

2. 问：TiDB的Region是什么？为什么采用Range分片而非Hash分片？
   答：Region是TiDB数据分片、副本管理、调度的最小单元（默认96MB），维护一段连续Key范围，自动分裂/合并/迁移。
   选Range分片的核心原因：① 天然适配范围查询、分页查询，避免Hash分片的跨节点聚合；② 便于PD做热点调度、负载均衡；③ 相邻数据可合并存储，减少空间浪费。
   高频星级：★★★★★

3. 问：TiDB的高可用实现原理？
   答：基于Raft分布式共识协议实现：

   • 每个Region默认3副本，跨节点/可用区部署，仅多数副本写入成功才返回成功，保证数据强一致；
   • Raft Leader负责读写，Follower同步日志；Leader故障时，剩余副本秒级自动选主切换，RPO=0，RTO<30s。
     高频星级：★★★★

（三）OceanBase专属架构核心考点

1. 问：OceanBase的核心架构与组件职责？
   答：OB采用计算存储一体化的Share-Nothing对等架构，所有节点功能一致，核心三大组件：

   • OBProxy（接入层）：无状态反向代理，统一接入入口，负责SQL精准路由、读写分离、负载均衡、故障转移；
   • RootService（总控层）：集群大脑，内置在OBServer，Paxos多副本高可用，核心负责全局GTS时间戳分配、元数据管理、分区调度、租户资源管理、故障切换；
   • OBServer（核心节点）：计算存储一体化，同时负责SQL计算与数据存储，原生支持内核级多租户，是数据与事务处理的核心载体。
     高频星级：★★★★★

2. 问：OB计算存储一体化 vs TiDB计算存储分离，核心区别是什么？
   答：

高频星级：★★★★★

1. 问：OB原生多租户的核心优势？
   答：内核级多租户是OB的核心特性，实现租户间CPU、内存、IO、网络资源完全强隔离，每个租户可独立选择MySQL/Oracle兼容模式，相当于独立数据库实例；可实现多业务系统统一部署、统一运维，大幅提升资源利用率，降低硬件成本。
   高频星级：★★★★

（四）架构类高频深挖对比考点

1. 问：TiDB与OB的数据分片能力核心差异？
   答：TiDB仅支持Range范围分片，自动分裂合并，适配范围查询场景；OB支持Range、Hash、List、复合分片全模式，灵活度更高，可适配高并发随机读写、多租户、地域级分片等全场景。
   高频星级：★★★★

2. 问：二者共识协议的选型与差异？
   答：TiDB采用Raft协议，实现简单，易运维，适合互联网通用场景；OB采用Paxos协议，容错性、可靠性更强，支持更灵活的副本部署策略，适配金融级三地五中心容灾场景，城市级故障可实现无损切换。
   高频星级：★★★★

二、分布式事务模块（面试核心深挖区，拉开分差关键，★★★★★全覆盖）

（一）必背基础考点

1. 问：分布式事务的核心挑战？
   答：核心挑战为跨节点的ACID保证，具体包括：① 全局有序性，保证跨节点事务的提交顺序；② 原子性，跨节点操作要么全成功要么全回滚；③ 一致性，保证全局数据一致；④ 性能与一致性的平衡，避免分布式事务开销过大。
   高频星级：★★★★★

2. 问：全局时间戳（TSO/GTS）在分布式事务中的核心作用？
   答：全局时间戳是分布式事务的核心基础，由集群总控节点统一分配，全局唯一、单调递增，核心作用：① 实现全局MVCC多版本控制，保证事务的快照隔离；② 界定事务的可见性，事务仅能读取小于自身起始时间戳的已提交版本；③ 保证跨节点事务的全局有序性，解决分布式场景下的时钟不一致问题。
   高频星级：★★★★★

（二）TiDB专属事务核心考点

1. 问：TiDB的分布式事务核心模型是什么？
   答：TiDB基于Google Percolator分布式事务模型，原生支持乐观事务、悲观事务双模型，默认采用与MySQL完全兼容的悲观事务模型。
   高频星级：★★★★★

2. 问：TiDB Percolator模型的两阶段提交（2PC）核心流程？
   答：

   1. Prewrite阶段：选定一个Primary Key，其余为Secondary Key；对所有修改的Key写入Prewrite记录与锁，校验版本冲突，冲突则回滚；所有Key Prewrite成功方可进入提交阶段。
   2. Commit阶段：获取commit_ts，先提交Primary Key，写入Commit记录并释放锁；Primary Key提交成功，事务即全局成功，后续异步提交所有Secondary Key。
      高频星级：★★★★★

3. 问：TiDB乐观事务 vs 悲观事务，核心区别与适用场景？
   答：

高频星级：★★★★★

1. 问：TiDB事务的核心性能优化手段？
   答：核心优化包括：① 1PC优化：单Region事务跳过2PC流程，直接提交，大幅降低延迟；② 异步提交优化：Secondary Key异步提交，减少提交等待时间；③ 组提交优化：多个事务日志合并写入，减少磁盘IO。
   高频星级：★★★★

（三）OceanBase专属事务核心考点

1. 问：OB的分布式事务核心实现？
   答：OB基于原生两阶段提交（2PC）+ 全局GTS时间戳 + Paxos共识协议实现分布式事务，主打悲观事务模型，针对金融级交易场景极致优化；单分区事务自动优化为1PC提交，仅跨分区/跨节点事务执行完整2PC流程。
   高频星级：★★★★★

2. 问：OB分布式事务的完整2PC核心流程？
   答：

   1. 事务开启：协调者节点获取start_scn（起始版本号），执行DML时加悲观行锁；
   2. Prepare阶段：协调者向所有参与者发送Prepare请求，参与者将事务日志通过Paxos同步到多数副本并持久化，锁定资源，返回成功；任意参与者失败则全局回滚；
   3. Commit阶段：所有参与者Prepare成功，协调者发送Commit请求，参与者提交事务、释放锁，全部成功后向客户端返回提交成功。
      高频星级：★★★★★

3. 问：OB事务的核心性能优化手段？
   答：核心优化包括：① 1PC极致优化：单分区单机事务跳过Prepare阶段，直接提交，减少一半网络与IO开销，绝大多数OLTP场景可命中；② 组提交优化：多事务日志合并持久化，降低磁盘IO；③ 只读事务优化：只读事务无锁、无提交开销，直接快照读取；④ 全局死锁检测：实时检测跨节点死锁，自动回滚低代价事务。
   高频星级：★★★★

（四）事务类高频深挖对比考点

1. 问：TiDB与OB分布式事务实现的核心差异？
   答：

高频星级：★★★★★

三、HTAP核心模块（NewSQL核心竞争力，高频进阶考点）

（一）必背基础考点

1. 问：HTAP的核心定义与解决的痛点？
   答：HTAP（Hybrid Transactional/Analytical Processing，混合事务/分析处理），指一套数据库架构同时支撑高并发OLTP交易与实时OLAP分析；核心解决传统TP/AP分离架构的数据冗余、ETL链路长、分析延迟高、运维复杂度高的痛点，实现业务数据的实时分析。
   高频星级：★★★★★

（二）TiDB专属HTAP核心考点

1. 问：TiDB的HTAP核心实现架构？
   答：TiDB采用行存+列存双引擎、双副本、资源物理隔离的HTAP架构：

   • 行存引擎TiKV负责OLTP交易，列存引擎TiFlash负责OLAP分析；
   • TiFlash是TiKV的Raft Learner副本，仅同步Raft日志，不参与投票选主，完全不影响OLTP性能；
   • 数据从TiKV实时同步到TiFlash，自动转列存，同步延迟毫秒级，通过TSO保证全局快照一致性；
   • CBO优化器自动识别查询类型，智能路由到对应引擎，OLAP查询采用MPP大规模并行执行框架。
     高频星级：★★★★★

2. 问：TiDB如何保证HTAP场景下TP与AP的资源隔离？
   答：核心通过物理隔离实现：TiKV与TiFlash部署在独立的物理节点，CPU、内存、磁盘IO、网络资源完全隔离，OLAP大查询无论负载多高，都不会抢占OLTP业务的资源，彻底解决资源抢占问题。
   高频星级：★★★★

（三）OceanBase专属HTAP核心考点

1. 问：OB的HTAP核心实现架构？
   答：OB采用原生行列融合一体化HTAP架构，分为基础版与进阶版：
   • 基础版：单副本行列融合存储，基线数据宏块内微块列式存储，一份数据同时适配OLTP点查与OLAP分析，无数据冗余；
   • 进阶版：行列融合+专用列存副本，列存副本基于Paxos与行存副本实时同步，独立部署实现物理资源隔离，适配超大规模OLAP场景；
   • 双执行引擎：同时支持OLTP火山模型与OLAP向量化+MPP并行执行，CBO优化器自动选择最优执行路径。
     高频星级：★★★★★

（四）HTAP类高频深挖对比考点

1. 问：TiDB与OB的HTAP实现核心差异？
   答：

高频星级：★★★★★

四、面试压轴综合题（终面必问，★★★★★）

问：TiDB与OceanBase的核心区别，以及选型建议？
答：

1. 核心区别总结

   • 架构层面：TiDB是计算存储分离的分层架构，组件解耦，扩展灵活；OB是计算存储一体化的对等架构，部署运维简单，延迟更低。
   • 生态兼容：TiDB主打100% MySQL兼容，开源生态成熟；OB原生支持MySQL/Oracle双兼容，Oracle替换能力行业领先。
   • 核心场景：TiDB适配互联网高并发OLTP+实时分析场景；OB主打金融级核心交易系统，经过超大规模流量验证，容灾、可靠性、多租户能力更强。
   • 事务与HTAP：TiDB基于Percolator事务模型，HTAP双副本物理隔离；OB原生2PC事务优化更极致，HTAP行列融合架构存储成本更低。

2. 选型建议

   • 优先选TiDB：业务基于MySQL开发，需零改造迁移；互联网高并发场景，需要开源生态与云原生适配；业务快速迭代，需灵活的扩缩容能力。
   • 优先选OceanBase：金融级核心交易系统，需极致的高可用与容灾能力；基于Oracle开发的业务，需国产化替换；超大规模业务，需高压缩比降低存储成本；多业务系统整合，需内核级多租户能力。