TiDB 是一个分布式 NewSQL (SQL 、 NoSQL 和 NewSQL 的优缺点比较 )数据库。它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适合 OLAP 场景的混合数据库。下面是对有关资料的整理还有一些扩展内容以链接的方式展示，有兴趣可以点击了解一下。
一 TiDb简介
TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP(Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。TiDB 具备如下核心特点：
1 高度兼容 MySQL
大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。
2水平弹性扩展
通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。
3分布式事务
TiDB 100% 支持标准的 ACID 事务。
4 真正金融级高可用
相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。
5 一站式 HTAP 解决方案
TiDB 作为典型的 OLTP 行存数据库，同时兼具强大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP解决方案，一份存储同时处理OLTP & OLAP(OLAP、OLTP的介绍和比较 )无需传统繁琐的 ETL 过程。
6云原生 SQL 数据库
TiDB 是为云而设计的数据库，同 Kubernetes （十分钟带你理解Kubernetes核心概念 ）深度耦合，支持公有云、私有云和混合云，使部署、配置和维护变得十分简单。
TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析可以通过 TiSpark 项目来完成。 TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力.
优点
水平扩展性：TiDB 可以轻松地通过添加更多的节点来实现横向扩展，这使得它非常适合需要处理大量数据的应用场景。
高可用性和容错能力：借助于 Raft 共识算法，TiDB 提供了自动故障转移和数据冗余功能，确保即使在硬件故障的情况下也能保持服务的连续性。
兼容 MySQL 协议：对于已经使用 MySQL 的用户来说，TiDB 的一大优势是其兼容 MySQL 协议，这意味着现有的应用可以几乎不做修改就迁移到 TiDB 上。
强一致性：TiDB 支持分布式事务，并保证了事务的 ACID 属性，提供了与单机数据库相似的一致性体验。
实时 HTAP 支持：TiDB 能够同时处理在线事务处理 (OLTP) 和在线分析处理 (OLAP) 工作负载，无需额外的数据迁移或 ETL 过程。
云原生友好：TiDB 设计时考虑到了云环境的需求，支持容器化部署、自动化运维等特性，易于在公有云、私有云或混合云环境中部署和管理。
缺点
复杂性：虽然 TiDB 对用户隐藏了许多分布式系统的复杂性，但对于数据库管理员(DBA)和运维团队而言，理解和管理这样一个复杂的系统仍然需要时间和学习成本。
性能开销：尽管 TiDB 在许多方面都进行了优化，但与单机数据库相比，在某些特定的工作负载下可能仍会遇到性能瓶颈或额外的延迟。
生态系统成熟度：尽管 TiDB 社区活跃且发展迅速，但与更成熟的数据库解决方案相比，其周边工具链、第三方集成和支持资源相对较少。
学习曲线：对于习惯了传统关系型数据库的开发人员和 DBA 来说，掌握 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。
PD 是一个集群，需要部署奇数个节点，一般线上推荐至少部署 3 个节点。
３TiKV Server
TiKV Server 负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range （从 StartKey 到EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region 。TiKV 使用 Raft协议做复制，保持数据的一致性和容灾。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 RaftGroup，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，这里也是以 Region 为单位进行调度。