只要15分钟，TiDB国产化数据库快速入门，简单高效

引言：
为什么要使用国产化数据库？
原因：
政府原因：2025年中国数据库要实现国产化，很多国营企业要国产化数据库

性能原因：TiDB数据库，相比于传统mysql，更加强大，能存储更多的数据，突破之前mysql的性能，mysql单表5000w数据之后就要考虑中间件进行分库分表

兼容原因：TiDB数据库，可以兼容mysql数据库进行迁移，同时他还能保证数据库的ACID，也有悲观锁和乐观锁，默认悲观锁。可以百分百保证数据的强一致性

1.TiDB服务部署

官方网站：https://docs.pingcap.com/zh/tidb/stable/dev-guide-build-cluster-in-cloud

Linux服务器部署测试（单机版安装部署）：

curl --proto ‘=https’ --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh

替换模板：
source ${your_shell_profile}

例如：
source /home/lanxi/.bashrc

启动方式有三种：

1. tiup playground （不指定核心组件参数）

2. tiup playground v8.1.0 --db 2 --pd 3 --kv 3 （指定核心组件参数，这几个核心组件下文会介绍其功能）

3. tiup playground v8.1.0 --db 2 --pd 3 --kv 3 --host 192.168.1.102 （指定核心组件参数，且外部可访问，推荐，192.168.1.102替换为自己服务器IP即可）

2.TiDB服务核心组件说明

可以进入控制面板，TiDB Dashboard 的这个地址，就可以看到各个核心组件的健康状态
以我自己例如：http://192.168.1.106:2382/dashboard

TiDB有这三个非常重要的核心组件，PD，TiDB，TiKV，TiFlash

2.1 PD（Placement Driver）- 交通指挥中心

想象一下 PD 就像是一个城市的交通指挥中心。它负责整个数据库集群的元数据管理，比如数据存储的分布、数据的复制和均衡等。就像交通指挥中心监控和调度车辆流一样，PD 监控和调度数据流，确保数据在整个集群中均匀分布，并且副本保持最新的状态。
总结：负责调度和监控

2.2 TiDB（SQL Layer）- 餐厅前台

TiDB 组件是与用户直接交互的 SQL 层，就像餐厅的前台接待一样。当用户提交 SQL 请求时，TiDB 负责解析这些请求，制定执行计划，并把这些请求转换成可以在底层存储系统中执行的操作。就像前台接待把顾客引导到空位上一样，TiDB 把数据请求引导到正确的数据存储位置。
总结：负责接受SQL请求和返回SQL结果

2.3 TiKV（分布式存储层）- 仓库存储系统

TiKV 是 TiDB 的存储层，它以键值对的形式存储数据。想象一下 TiKV 就像一个巨大的自动化仓库，每个货物（数据）都有一个独特的货架位置（键）。当你需要存取货物时，你只需要提供正确的货架位置，仓库的自动化系统就会快速地帮你找到货物。TiKV 通过分布式的方式存储数据，确保数据的高可用性和容错性。
总结：负责存储数据并保证数据的高可用性

2.4 TiFlash（列式存储引擎）- 快速分析机器

TiFlash 是 TiDB 的列式存储引擎，主要用于 OLAP（在线分析处理）场景。可以把它想象成一个高效的数据分析机器，它能够快速处理和分析大规模数据集。就像一个拥有高速处理器和优化算法的分析机器，TiFlash 可以快速生成报告和数据分析结果，特别适合处理复杂的查询和报表需求。
总结：负责快速处理分析型查询

3.TiDB功能使用

3.1 数据共享

这样的好处就是，KV可以专注于存储数据，DB会进行数据同步，将来服务只需要在Nginx服务上分配多个DB负载去请求即可，减少数据库请求压力

例如：

3.2 数据类型对比mysql的差异

数值类型：TiDB支持整数类型（如TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT）和浮点数类型（如FLOAT, DOUBLE），以及定点数类型（如DECIMAL/NUMERIC）。这些类型在TiDB和MySQL中基本相同，但TiDB在某些情况下可能会有更严格的精度要求。

字符串类型：TiDB支持CHAR（定长字符串）、VARCHAR（变长字符串）、TEXT（大文本数据）、BINARY/VARBINARY（二进制字符串）、以及BLOB（二进制大文件）。这些类型在TiDB中的定义和使用与MySQL类似。

日期和时间类型：TiDB支持的日期和时间类型也与MySQL相似，包括DATE、TIME、DATETIME、TIMESTAMP和YEAR。这些类型在TiDB中的行为与MySQL中的行为一致。

枚举（ENUM）和集合（SET）类型：TiDB支持ENUM和SET类型，这些类型允许你在一组预定义的值中选择。在TiDB中，这些类型内部使用数值来存储，但对外表现上是字符串。

JSON类型：TiDB支持JSON类型，允许存储JSON格式的数据。这与MySQL中的JSON类型相似，但TiDB的JSON类型是实验性的，不建议在生产环境中使用。

空间类型（SPATIAL）：TiDB不支持MySQL的空间类型，如GEOMETRY，这与MySQL的一个主要区别。

数据类型定义：在TiDB中，数据类型定义一般为 T(M[, D])，其中M表示最大显示长度（整数类型）、精度（浮点数或定点数）、或最大长度（字符类型），D表示小数位长度。这与MySQL的定义方式相似，但TiDB对某些类型可能有特定的限制或优化。

总的来说，TiDB的数据类型系统与MySQL高度兼容，但在某些高级特性和内部实现上可能存在差异。开发者在使用TiDB时，应该参考TiDB的官方文档来了解具体的数据类型行为和限制。

3.3 TiDB环境部署要求

硬件配置要求：
开发及测试环境：
TiDB: 至少8核CPU，16GB+内存，无特殊存储要求，至少千兆网卡，至少1实例（可与PD同机器）。
PD: 至少4核CPU，8GB+内存，至少200GB SAS存储，至少千兆网卡，至少1实例（可与TiDB同机器）。
TiKV: 至少8核CPU，32GB+内存，至少200GB SSD存储，至少千兆网卡，至少3实例。
TiFlash: 至少32核CPU，64GB+内存，至少200GB SSD存储，至少千兆网卡，至少1实例。
TiCDC: 至少8核CPU，16GB+内存，至少200GB SAS存储，至少千兆网卡，至少1实例。

生产环境：
TiDB: 至少16核CPU，48GB+内存，SSD存储，至少万兆网卡（推荐2块），至少2实例。
PD: 至少8核CPU，16GB+内存，SSD存储，至少万兆网卡（推荐2块），至少3实例。
TiKV: 至少16核CPU，64GB+内存，SSD存储，至少万兆网卡（推荐2块），至少3实例。
TiFlash: 至少48核CPU，128GB+内存，1个或多个SSD存储，至少万兆网卡（推荐2块），至少2实例。
TiCDC: 至少16核CPU，64GB+内存，SSD存储，至少万兆网卡（推荐2块），至少2实例。
监控: 至少8核CPU，16GB+内存，SAS存储，至少千兆网卡，至少1实例。

网络要求：
需要为TiDB组件开放相应的默认端口，例如TiDB的4000端口、PD的2379端口、TiKV的20160端口等 。

磁盘空间要求：
对于生产环境，TiDB建议日志盘至少预留30GB，PD的数据盘和日志盘各至少20GB，TiKV的数据盘和日志盘各至少100GB，TiFlash的数据盘至少100GB，日志盘至少30GB 。
客户端Web浏览器要求：
需要支持现代Web技术的浏览器，以便访问TiDB的监控和管理系统。
请注意，这些是最低要求，实际部署时可能需要根据具体业务需求进行调整。建议参考TiDB的官方文档获取最新的硬件和软件配置要求