简介
开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP) 的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。
SQL 基本操作
分类
SQL 语言通常按照功能划分成以下的 4 个部分：
- DDL (Data Definition Language)：数据定义语言，用来定义数据库对象，包括库、表、视图和索引等。
- DML (Data Manipulation Language)：数据操作语言，用来操作和业务相关的记录。
- DQL (Data Query Language)：数据查询语言，用来查询经过条件筛选的记录。
- DCL (Data Control Language)：数据控制语言，用来定义访问权限和安全级别。
常用的 DDL 功能是对象（如表、索引等）的创建、属性修改和删除，对应的命令分别是 CREATE、ALTER 和 DROP。
查看、创建和删除数据库
-- 查看数据库列表
SHOW DATABASES;
-- 使用名为 mysql 的数据库
USE mysql;
-- 查看数据库中的所有表
SHOW TABLES FROM mysql;
-- 创建数据库
CREATE DATABASE db_name [options];
-- 例如，要创建一个名为 samp_db 的数据库
CREATE DATABASE IF NOT EXISTS samp_db;
-- 添加 IF NOT EXISTS 可防止发生错误。
-- 删除数据库。
DROP DATABASE samp_db;
创建、查看和删除表
-- 创建表
CREATE TABLE table_name column_name data_type constraint;
-- 例如，要创建一个名为 person 的表，包括编号、名字、生日等字段
CREATE TABLE person (
id INT(11),
name VARCHAR(255),
birthday DATE
);
-- 查看建表语句
SHOW CREATE TABLE person；
-- 删除表
DROP TABLE person;
创建、查看和删除索引
-- 索引通常用于加速索引列上的查询。对于值不唯一的列，可使用 CREATE INDEX 或 ALTER TABLE 语句创建普通索引。
CREATE INDEX person_id ON person (id);
-- 或者
ALTER TABLE person ADD INDEX person_id (id);
-- 对于值唯一的列，可以创建唯一索引
CREATE UNIQUE INDEX person_unique_id ON person (id);
-- 或者
ALTER TABLE person ADD UNIQUE person_unique_id (id);
-- 查看表内所有索引
SHOW INDEX FROM person;
-- 删除索引
DROP INDEX person_id ON person;
-- 或者
ALTER TABLE person DROP INDEX person_unique_id;
DDL 操作不是事务，无需 COMMIT。
记录的增删改
-- 向表内插入表记录
INSERT INTO person VALUES(1,'tom','20170912');
-- 向表内插入包含部分字段数据的表记录
INSERT INTO person(id,name) VALUES('2','bob');
-- 表内修改表记录的部分字段数据
UPDATE person SET birthday='20180808' WHERE id=2;
-- 向表内删除部分表记录
DELETE FROM person WHERE id=2;
-- 注意：UPDATE 和 DELETE 操作如果不带 WHERE 过滤条件是对全表进行操作。
记录的查询
DQL 数据查询语言是从一个表或多个表中检索出想要的数据行，通常是业务开发的核心内容。
-- 检索表内数据
SELECT * FROM person;
-- 在 SELECT 后面加上要查询的列名
SELECT name FROM person;
+------+
| name |
+------+
| tom |
+------+
-- 使用 WHERE 子句，对所有记录进行是否符合条件的筛选后再返回
SELECT * FROM person WHERE id<5;
创建、授权和删除用户
常用的 DCL 功能是创建或删除用户，和对用户权限的管理。
-- 创建一个用户 tiuser，密码为 123456
CREATE USER 'tiuser'@'localhost' IDENTIFIED BY '123456';
-- 授权用户 tiuser 可检索数据库 samp_db 内的表
GRANT SELECT ON samp_db.* TO 'tiuser'@'localhost'
-- 查询用户 tiuser 的权限
SHOW GRANTS for tiuser@localhost;
-- 删除用户 tiuser
DROP USER 'tiuser'@'localhost';
部署集群
软硬件环境建议配置。
环境与系统配置检查。
配置拓扑结构：使用不同的存储引擎 TiFlash TiCDC，使用不同的组件 TiDB Binlog TiSpark，集群的拓扑结构也不同。
-最小：TiDB 3个实例、PD 3个实例、TiKV 3个实例、Monitoring & Grafana 1个实例
-跨数据中心部署拓扑结构
-混合部署拓扑结构
安装与启动
-使用集群运维工具 TiUP 部署
-使用集群部署工具 TiDB Ansible 部署(TiDB 4.0 版本开始不再维护)
验证集群状态。通过 TiDB Dashboard 和 Grafana
性能测试方法：
-Sysbench
-如何进行 TPC-C(一个对 OLTP 系统进行测试的规范)测试
数据迁移
从 MySQL、CSV 文件、SQL 文件等将数据迁移到 TiDB。
运维操作
升级 TiDB 版本。
扩(缩)容。
备份与恢复。BR工具。
读取历史数据。
修改时区。
日常巡检。
TiFlash 集群常用运维操作。
使用 TiUP 工具对集群的常用运维操作。
使用 TiDB Ansible 工具(TiDB 4.0 后不再维护)的常见运维操作。
在线修改集群配置。通过 sql。实验阶段。
监控和告警
TiDB 使用开源时序数据库 Prometheus 作为监控和性能指标信息存储方案，使用 Grafana 作为可视化组件进行展示。
故障诊断
定位慢查询
TiDB 会将执行时间超过 slow-threshold（默认值为 300 毫秒）的语句输出到 slow-query-file（默认值：“tidb-slow.log”）日志文件中，用于帮助用户定位慢查询语句，分析和解决 SQL 执行的性能问题。
TiDB 默认启用慢查询日志，可以修改配置 enable-slow-log 来启用或禁用它。
分析慢查询
sql 诊断
定位消耗系统资源过多的查询
sql 语句统计
TiDB 集群常见问题
TiDB 集群问题导图
热点问题处理
CPU 占用过多导致读写延迟增加
写冲突与写性能下降
磁盘 I/O 过高
锁冲突与 TTL 超时
TiFlash 常见问题
性能调优
系统调优：操作系统性能参数调优
软件调优：
-配置
–TiDB 内存调优
–TiKV 线程调优
–TiKV 内存调优
–TiKV Follower Read
–TiFlash 调优
-下推计算结果缓存
SQL 性能调优
教程
生态工具
参考指南
TiDB 技术内幕
说存储
TiKV 解决数据存储的问题。
TiKV 存储数据的数据结构是 Key-Value。
TiKV 是一个巨大的 Map，存储的是 Key-Value 对。
这个 Map 的 Key-Value 对按照 Key 的二进制顺序有序，我们可以 Seek 到某一个 Key 的位置，然后不断地调用 Next 方法以递增的顺序获取比这个 Key 大的 Key-Value。
这里的存储模型和 SQL 中的 Table 无关！！！
总结一下，通过单机的 RocksDB，我们可以将数据快速地存储在磁盘上；通过 Raft，我们可以将数据复制到多台机器上，以防单机失效。数据的写入是通过 Raft 这一层的接口写入，而不是直接写 RocksDB。通过实现 Raft，我们拥有了一个分布式的 KV，现在再也不用担心某台机器挂掉了。
Region
对于一个 KV 系统，为了实现存储的水平扩展，我们需要将数据分散在多台机器上。有两种比较典型的方案：一种是按照 Key 做 Hash，根据 Hash 值选择对应的存储节点。另一种是分 Range，某一段连续的 Key 都保存在一个存储节点上。TiKV 选择了第二种方式，将整个 Key-Value 空间分成很多段，每一段是一系列连续的 Key，我们将每一段叫做一个 Region，并且我们会尽量保持每个 Region 中保存的数据不超过一定的大小(这个大小可以配置，目前默认是 96mb)。每一个 Region 都可以用 StartKey 到 EndKey 这样一个左闭右开区间来描述。将数据划分成 Region 后，我们将会做 两件重要的事情：
- 以 Region 为单位，将数据分散在集群中所有的节点上，并且尽量保证每个节点上服务的 Region 数量差不多
- 以 Region 为单位做 Raft 的复制和成员管理
先看第一点，数据按照 Key 切分成很多 Region，每个 Region 的数据只会保存在一个节点上面。我们的系统会有一个组件来负责将 Region 尽可能均匀的散布在集群中所有的节点上，这样一方面实现了存储容量的水平扩展（增加新的结点后，会自动将其他节点上的 Region 调度过来），另一方面也实现了负载均衡（不会出现某个节点有很多数据，其他节点上没什么数据的情况）。同时为了保证上层客户端能够访问所需要的数据，我们的系统中也会有一个组件记录 Region 在节点上面的分布情况，也就是通过任意一个 Key 就能查询到这个 Key 在哪个 Region 中，以及这个 Region 目前在哪个节点上。至于是哪个组件负责这两项工作，会在后续介绍。
对于第二点，TiKV 是以 Region 为单位做数据的复制，也就是一个 Region 的数据会保存多个副本，我们将每一个副本叫做一个 Replica。Replica 之间是通过 Raft 来保持数据的一致（终于提到了 Raft），一个 Region 的多个 Replica 会保存在不同的节点上，构成一个 Raft Group。其中一个 Replica 会作为这个 Group 的 Leader，其他的 Replica 作为 Follower。所有的读和写都是通过 Leader 进行，再由 Leader 复制给 Follower。
我们以 Region 为单位做数据的分散和复制，就有了一个分布式的具备一定容灾能力的 KeyValue 系统，不用再担心数据存不下，或者是磁盘故障丢失数据的问题。但是还不够。
MVCC
