TiDB经验分享01

前言

这篇博客是博主根据自己过去一年多工作中使用TiDB的经验分享，最近因为业务增长 遇到TiDB sql慢查询问题，在排查发现并解决问题的过程中 根据自己对TiDB的一些了解和学习 总结出该篇博客。

基础知识

在讲述某个技术栈的使用时 一般我们需要对该项技术内在的一些原理和基础知识有一定的了解，这里南国假设你之前已经使用过MySQL 并对MySQL的一些基础知识有一定的了解 例如索引 一条SQL内在的执行过程 MySQL集群主从复制 一主多从等等，如果这些内容你还是第一次听到或者没有遇到过 建议你提前在网上看看相关的知识点 或者看看博主之前关于MySQL的博客 对一些基础知识有个大概了解。

对一项技术 系统性的学习最好的学习方式就是看官网的资料了 TiDB官网
TiDB 是 PingCap（平凯星辰）公司推出的开源 New-SQL 数据库。TiDB 受 Google Spanner 和 F1 论文启发而设计，属于开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。
它是一款国产的数据库，官网文档也是中文，相比较于其它英文 阅读的门槛也会低很多。

这里博主不会详细展开对官网上的所有基础知识详细展开来讲，这也不是本文的重点，如果读者有足够的时间 也推荐大家阅读官网的一手最新资料。这里我就几个个人认为比较重要的基础知识点展开讲述一下：

TiDB的基础架构

TiDB 集群主要分为四个组件：

• TiDB Server(负责计算)
  TiDB Server 负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，最终返回结果。
  TiDB Server 是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVS、HAProxy 或 F5）对外提供统一的接入地址。
• PD Server(集群管理)
  Placement Driver (简称 PD) 是整个集群的管理模块，其主要工作有三个： 一是存储集群的元信息（某个 Key 存储在哪个 TiKV 节点），二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader 的迁移等），三是分配全局唯一且递增的事务 ID。
• TiKV Server(负责存储数据)
  TiKV Server 负责存储数据。存储数据的基本单位是 Region，每个 TiKV 节点会负责多个 Region 。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 Raft Group，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，这里也是以 Region 为单位进行调度。
• TiSpark
  TiSpark 是 PingCAP 为解决用户复杂 OLAP 需求而推出的产品。它借助 Spark 平台，同时融合 TiKV 分布式集群的优势，和 TiDB 一起为用户一站式解决 HTAP (Hybrid Transactional/Analytical Processing) 的需求。

整体的架构可用下面一张来表示：