【TiKV / HTAP 内核】TiDB SQL 层边界：一条计划如何打到 Region
内容提要
本文讨论了TiDB中SQL处理的关键步骤，重点介绍了如何将SQL请求路由到具体的Region。TiDB通过distsql模块将逻辑key范围映射到物理Region，并生成Coprocessor任务。文章还探讨了Region路由中的错误处理机制和重试策略，以及不同下推协议（Cop、BatchCop、MPP）的路由差异。最后，强调了优化器选择与路由层之间的独立性，以及点查与范围扫描的效率差异。
关键要点
-
TiDB通过distsql模块将逻辑key范围映射到物理Region，并生成Coprocessor任务。
-
Region路由的错误处理机制包括NotLeader和EpochNotMatch，触发重试策略。
-
三种下推协议（Cop、BatchCop、MPP）在路由层的请求粒度和目标引擎有所不同。
-
distsql模块控制并发度，避免对TiKV造成瞬时压力。
-
点查（Point Get）比范围扫描更高效，因为它直接使用KV接口发起请求，绕过了Coprocessor DAG机制。
-
Region路由信息可能因调度而过期，导致查询延迟抖动，需关注RegionCache的状态。
延伸解读
TiDB的SQL处理流程
TiDB的SQL处理分为六个步骤，其中关键在于如何将逻辑key范围映射到物理Region。理解这一过程有助于开发者优化查询性能，特别是在处理复杂的SQL请求时。
Region路由中的错误处理
在Region路由中，常见的错误如NotLeader和EpochNotMatch会导致请求重试。这些错误处理机制对查询性能有直接影响，开发者需关注相关指标，以便及时排查性能波动的原因。
下推协议的选择
TiDB支持三种下推协议（Cop、BatchCop、MPP），每种协议在请求粒度和目标引擎上有所不同。了解这些差异可以帮助开发者在特定场景下选择最优的查询策略，从而提高系统的整体效率。
点查与范围扫描的效率差异
点查（Point Get）通常比范围扫描更高效，因为它直接使用KV接口发起请求，避免了复杂的Coprocessor DAG机制。开发者在设计查询时应考虑这一点，以优化性能。
延伸问答
TiDB是如何将SQL请求路由到具体的Region的？
TiDB通过distsql模块将逻辑key范围映射到物理Region，并生成Coprocessor任务。
在TiDB中，Region路由的错误处理机制是什么？
Region路由的错误处理机制包括NotLeader和EpochNotMatch，触发重试策略。
TiDB中有哪些下推协议，它们的路由差异是什么？
TiDB中有三种下推协议：Cop、BatchCop和MPP，它们在请求粒度和目标引擎上有所不同。
为什么点查比范围扫描更高效？
点查直接使用KV接口发起请求，绕过了Coprocessor DAG机制，因此更高效。
TiDB的distsql模块如何控制并发度？
distsql模块通过系统变量控制并发度，避免对TiKV造成瞬时压力。
RegionCache在TiDB中有什么作用？
RegionCache本地缓存Region信息，避免每次都向PD查询，提高查询效率。
