目录
TiDB功能与特点
正确
具有同时支持OLTP与OLAP业务的能力（即支持HTAP）
能够同时存储一份数据的行存版本（TiKV）和列存版本（TiFlash），并保证一致性读取
不正确
TiDB数据库需要通过数据复制的方式(搭建从库）才能保证数据的高可用性
只有在云原生模式下，TiDB 数据库能够实现水平扩容或者缩容
TiDB Server功能
正确
TiDB Server在开始执行SQL语句时，会从PD节点获取当前的TSO
不正确
TiDB Server负责SQL的解析和编译，而PD负责（TiDB Server负责）在关系型数把和KV存储间相互转换
TiKV的元数据，在数据库启动后会全部载入到TiDB Server的缓存中，加快查询效率
即使TiDB有information schema提供“非持久化”的对表元数据的访问和TiKV Client提供最近使用过的region数据【region cache】，但也不可能将其全部载入到TiDB Server缓存
TiDB Server的缓存中除了有表的元数据外还会存储Online DDL的job 队列（由TiKV负责存储）
TiDB Server模块
正确
Executor模块负责执行SQL执行计划
不正确
PD Client模块只是负责TiDB Server向PD请求TSO，并接受返回的TSO（PD Client）
PD不仅负责TiDB Server向PD请求并接受TSO，还具有批处理功能为多个事务或SQL分配TSO
TiKV Client模块只负责执行Coprocessor request，比如，过滤，聚合或列投影等等，点查操作由KV模块直接发给TiKV
1.TiKV Client还负责缓存和提供TiKV region的元数据【region cache】，还负责与TiKV进行交互
2.必须通过TiKV Client与TiKV进行交互
DistSQL模块负责将包含JOIN，SUBQUERY等复杂算子和涉及很多的表的SQL抽象为只涉及到单个表数据的多个操作，并将这些操作直接发给TiKV（必须通过TiKV Client与TiKV进行交互）
TiDB Server将关系型数据（含有主键，并希望key中含有主键）转化为key-value数
1.将主键(Primary Key)单独分离出来，与表的Table ID拼接，作为 key序列
2.主键(Primary Key)对应的单行数据作为value，形成key-value对
3.将这些 key-value存储在一个region中
4.如果region大小超过96 MB，则分裂为2个（region大小范围96mb~144mb）
TiDB Server GC机制
正确
GC会被自动触发，默认是10分钟一次
每次GC操作过后，修改时间在safe point之前的旧版本数据快照可能会被删除掉，之后的不会
不正确
如果有多个TiDB Server，则这些TiDB Server可以并行来执行GC操作
只有作为GC leader的TiDB Server才能控制整个GC进行并行操作
GC life time是无法手工调整的，由系统根据数据库压力情况自动调整
可以通过GC_life_time参数设置保留多长时间的历史版本
TiDB Server缓存
正确
复杂SQL的查询中间结果，往往会存储在TiDB Server的缓存中
通过tidb-mem-quota-query参数能够控制每个查询的缓存使用量
oom-action参数用来设置SQL语句超过内存使用阈值后的行为
不正确
information schema和表的统计信息都是存储在TiDB Server的持久化存储中，启动后载入TiDBServer的缓存中（TiDB Server不负责数据的“落地 ”，即持久化，而应在TiKV中）
TiKV RocksDB
正确
持久化机制，同时保证性能和安全性
性能随CPU数量线性提升
RocksDB使用LSM存储引擎
不正确
支持key-value、json、xml和图数据的存储（仅支持key-value，图数据的存储）
TiKV RocksDB读写
正确
写入操作（增删改)的数据最开始都是保存在内存中的
immutable MemTable不支持继续写入
Level 0层的SST文件是immutable MemTable的转储
Column Families共享WAL文件
（图a）
不正确
WAL的作用是为了加速磁盘的写入速度，将随机写变为顺序写
WAL预写日志是为了保证写入的原子性和持久性，即使系统宕机也能进行故障恢复
读取时，内存中只读Block Cache，不会去读MemTable，目的是不会影响写的效率读取时，如果内存中没有找到的key一定不会出现在Level 0的SST文件中
1.读取时从Block Cache，至MemTable，在至immutable memTable和各级SST文件中
2.内存中未找到，不意味着磁盘中的各级SST文件中没有相应的数据
（图b）
Column Families共享SST文件（Column Families共享WAL文件，而不是SST文件，如上图a）
TiKV Raft日志复制 ：Propose ->Append -> Replicate ->Committed -> Apply
TiKV MVCC
正确
在TiDB 数据库中，一旦数据被修改并且事务被提交，新的读取(select操作并且tidb_snapshot="")则无法读取到修改之前的任何版本
不正确
MVCC机制只存在于支持分布式事务的数据库中
MVCC多版本并发控制，是现代数据库（包括 MySQL、Oracle、PostgreSQL 等）引擎实现中常用的处理读写冲突的手段；而不是支持分布式事务的数据库中独有的
只有当隔离级别为snapshot isolation或者repeatable read时候，MVCC才会生效
MVCC只在read commited和repeatable read两个隔离级别下工作，与隔离级别snapshot isolation无关
TiDB数据库中存储了数据从写入至当前的所有版本
由于垃圾回收GC的存在，生成的版本快照，每隔一段时间就会被清除，故不可能存储写入至当前的所有版本
TiKV读写
正确
单条select语句读取到的任何数据都是已经从raft log日志中apply到 RocksDB KV中的
最开始从PD中读取到的路由信息中的leader所在TiKV节点，不一定是最终读取数据的节点
TiKV有多种读取方式，ReadIndex Read，Lease Read均是从leader上读取数据；而Follower Read是从follower上读取数据
不正确
follower read不可能比leader read先读到数据
大多数情况下，follower read往往比leader read先读到数据，因为leader要等待Replicate和Commited阶段
当集群中所有的follower节点都收到了这个日志（ raft log )，我们才认为这个（ raft log )是commited（当大多数（超过一半的）follower将raft log持久化成功，才认为是commited）
TiKV Coprocessor
正确
Coprocessor功能能够减少TiDB Server与TiKV节点间的网络开销
表的统计信息收集可以借助Coprocessor由TiKV来完成
导入数据后的一致性校验可以借助Coprocessor由TiKV来完成
不正确
将SQL的计算下推到TiKV节点，TiDB Server不再负责SQL的计算，从而降低CPU使用率
算子下推只是根据物理执行计划，将一部分计算下推至TiKV节点，并不意味着TiDB Server不负责任何计算
PD TSO
正确
TSO的组成为︰物理时钟＋逻辑时钟
ps：TSO=物理时间 physical time + 逻辑时间 logical time （不能交换顺序）
TSO的申请者是通过PD Client模块来向PD申请TSO的
SQL语句的解析和编译可以与TSO的获取异步执行
PD发出的 TSO只会递增不会递减
时间本身是不断累积的，即使身为leader的PD宕机，也只能等待下一个时间窗口
不正确
当PD Client模块过于繁忙时，PD会直接将TSO返回给申请者
必须通过PD Client与PD的交互
PD label
正确
label的配置需要在PD和TiKV上进行操作
如果不使用label ，PD仅仅保证region的多个副本不会存储在同一个TiKV实例上
Label的作用之一是控制region副本的存放位置，比如 host，rack或者DC
不正确
Zone必须对应一个数据中心(DC)，不能对应一个机柜
server.label与location-labels设置的层级对应，不意味着与现实中的设备相对应，如果愿意 Zone可以代表TiKV节点
数据读取必须步骤
正确
获取到当前SQL开始执行的TSO
进行PointGet检测（点查的处理由TiDB Server的KV负责）
不正确
扫描RocksDB实例中所有SST文件
即使在内存中没找到数据，也不会扫描RocksDB中的所有SST，而是根据SST的储存层级至顶向下扫描直到找到最新的数据，详见TikV RocksDB读写-图b
扫描RocksDB实例中最新的WAL文件
WAL预写日志是为了保证写入的原子性和持久性并进行进行故障恢复，在查询中不会扫描描RocksDB实例中WAL文件
Online DDL
正确
Online DDL的job队列被持久化在TiKV中，不是TiDB Server中
详见TiDB Server功能关于DDL的内容
不正确
Online DDL操作指的是DDL操作并不影响线上业务，对于性能监控也是无感知的
如果有多个TiDB Server，所有TiDB Server中的worker模块会并行处理添加索引的操作，加快进度
同一时刻只有一个身为owner的Tidb server处理DDL操作，但是index queue中的索引DDL和job queue中的job是可以被owner并行执行的
接收到DDL SQL的TiDB Server，会先启动自己的worker模块处理DDL，之后根据负载情况可能转移给owner角色的TiDB Server中的worker模块处理
当接收到DDL SQL时，TiDB Server会先尝试检测自己的worker模块是否是owner角色，若不是这只能放入jop queue中等待owner角色的TiDB Server中的worker模块处理
满足HTAP的场景
正确
同时支持OLTP和OLAP两种业务（HTAP要求同时支持OLTP和OLAP）
承担着实时数据写入的行存，并且能够实时将数据变化同步到列存储
不正确
能够支持PB级数据分析（HTAP对高数据级别的数据分析没有要求）
能够支持高并发的交易场景，且保证强一致性
HTAP不适用于高并发的场景，同时异步复制，无法保证强一致性
TiDB数据库的MPP功能特性
正确
聚合查询也可以通过MPP功能提速
TiFlash节点的内存承担了MPP中的计算功能
MPP功能对于大表连接有提高效率的作用
MPP架构实现在TiFlash上对于聚合和连接操作的加速且仅支持等值连接，但只限于TiFlash，而不能作用于TiKV
不正确
将行存数据转为列存（由TiFlash的负责）
2896
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
