TiDB 追番手账(番外) TiDB Server内核原理学习笔记

这篇笔记主要通过对比TiDB Server和MariaDB Server 的工作过程,为熟悉MySQL的同学更好的理解TiDB Server 内核原理,如果有理解不当的部分,欢迎讨论~

TiDB Server 和MariaDB 的处理流程图,均摘自官网

TiDB Server,SQL层

MariaDB

SQL处理过程类似,通过客户端链接的协议处理,SQL解析,生成执行计划及优化,然后执行及返回结果。但每个环节的处理过程有很大区别。

客户端链接处理的不同:

TiDB:

一个集群中多个DB节点都可以读写

Get Token Duration:建立连接后获取 Token 耗时,没有其他连接数,超时时间的限制

MariaDB:

一个节点读写,多节点复制只读/自增配置多写,借助复杂中间件实现多写

Connections 最大连接数,最大用户连接数,各种Timeout,是否启用链接池,引擎层的线程并发限制等

SQL解析不同:

TiDB:通过PD获取数据在KV存储的位置,分解计算任务,聚合计算结果

MariaDB:根据统计信息,生成执行计划

SQL执行,存储层交互不同:

TiDB:

DML:生成执行计划,TiDB Server 需要通过PD节点了解逻辑上的表与KV存储的对应关系,拆分执行计划,运行SQL,如果一部分计算下推到TiKV运行,需要合并计算结果返回客户端

DDL:online修改字段比修改索引快,原因有两篇文章解释的非常清楚~

TiDB Server 的理论基础Google F1 的 schema 变更算法深度解析请戳https://github.com/ngaut/builddatabase/blob/master/f1/schema-change.md

TiDB Server DDL变更流程说明

https://github.com/ngaut/builddatabase/blob/master/f1/schema-change-implement.md

MariaDB:根据执行计划调用引擎提供的接口获取数据,DDL需要以某种形式重建表复制数据,online 变更需要借助外部工具

SQL的行为,事务的管理结合存储层实现:基于MVCC,两阶段提交

TiDB:乐观并发控制,提交时一次性检测冲突,发现冲突就回滚

MariaDB:悲观事务模型,行锁避免冲突,死锁检测回滚冲突

非常深入地对比分析:+1: