一 简介:介绍新型NEW SQL数据库tidb
二 目的: tidb出现的目的,就是代替mysql+中间件,实现横向水平扩展
三 核心理论观点
1 MySQL 是单机数据库，只能通过 XA 来满足跨数据库事务，而 TiDB 本身就通过 Google 的 Percolator 事务模型支持分布式事务，性能稳定性比 XA 要高出很多，所以不会也不需要支持 XA。也就是说tidb并不是依靠XA事务实现的分布式一致性
2 三层架构
TiDB 是 Server 计算层，主要负责 SQL 的解析、制定查询计划、生成执行器。,是消耗资源的主要进程,主要消耗 cpu 内存
TiKV 是分布式 Key-Value 存储引擎，用来存储真正的数据，简而言之，TiKV 是 TiDB 的存储引擎,采用raft协议,多地备份实现高可用(数据可用+服务可用) 无重要消耗
PD 是 TiDB 集群的管理组件，负责存储 TiKV 的元数据，同时也负责分配时间戳以及对 TiKV 做负载均衡调度 主要消耗 磁盘,最好SSD
3 TiDB 和mysql兼容性对比
1 不支持 存储过程与函数 视图 触发器 事件 自定义函数 外键约束 全文索引 空间索引 非 utf8 字符集 增加主键 删除主键 SYS schema MySQL 追踪优化器 X Protocol
2 TiDB 的自增 ID (Auto Increment ID) 只保证自增且唯一，并不保证连续分配,它的分片方式是 节点1 分配一段ID,节点2 再分配另一段ID,以此类推 建议不要混用缺省值和自定义值(要么都指定自增ID,要么都使用默认值)
3 Performance schema 表在 TiDB 中返回结果为空。TiDB 使用 Prometheus 和 Grafana 来监测性能指标。
4 TiDB 支持常用的 MySQL 内建函数，但是不是所有的函数都已经支持，具体请参考语法文档。
5 DDL 操作 大多不会阻塞线上DML 但是要注意 有些会阻塞,而且有些并不支持
1 针对主键的操作 删除 增加
2 同时进行的操作,比如同时增加列 同时增加索引等
6 TiDB 使用乐观事务模型，在执行 Update、Insert、Delete 等语句时，只有在提交过程中才会检查写写冲突，而不是像 MySQL 一样使用行锁来避免写写冲突。所以业务端在执行 SQL 语句后，需要注意检查 commit 的返回值，即使执行时没有出错，commit的时候也可能会出错。
7 针对load date
TiDB 在执行 load data 时，默认每 2 万行记录作为一个事务进行持久化存储。如果一次 load data 操作插入的数据超过 2 万行，那么会分为多个事务进行提交。如果某个事务出错，这个事务会提交失败，但它前面的事务仍然会提交成功，在这种情况下一次 load data 操作会有部分数据插入成功，部分数据插入失败。
而 MySQL 中会将一次 load data 操作视为一个事务，如果其中发生失败情况，将会导致整个 load data 操作失败。
8 tidb 针对大事务的限制
9 tidb的explain和mysql的是不一致的
10 默认sql_mode
tidb STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION
11 隔离级别
tidb TiDB 实现的是论文中的 snapshot 隔离级别，该隔离级别不会出现幻读，但是会出现写偏斜
mysql ANSI 可重复读隔离级别不会出现写偏斜，会出现幻读。
12 tidb 所需要的软硬件环境(推荐最佳配置)
系统环境 centos 7.3+
网卡 双万兆网卡
三层架构
tidb sas
pd ssd
tikv ssd
监控 sas
tikv 硬盘大小配置建议 PCI-E SSD 不超过 2 TB，普通 SSD 不超过 1.5 TB。
tidb pd tikv 三者都放在单独的服务器上
补充 整个 TiDB 架构是面向未来、面向海量数据高并发场景，底层存储技术（如数据定位 seek）都是针对当前主流的 SSD 进行设计和优化的，不会对传统的 SATA/SAS 机械硬盘再进行优化。