关于 TiDB 的 37 个知识点解析

1.TiDB数据库的三层架构包括哪些？

答：调度引擎（PD）、存储引擎（TiKV）、计算引擎（TiDB-Server）。

2.TiDB数据库的内核组件有哪些？

答：内核组件包括 PD、TiKV、TiDB-Server，只有TiKV有数据文件，所有节点都有配置文件和日志文件。

3.TiDB数据库是否必须多节点？

答：如不考虑高可用测试环境，TiDB/TiKV/PD节点的个数都可以是1个，也可以按需后期添加TiFlash、TiCDC和Binlog组件。

4.TiDB-Server负责哪些工作？

答：TiDB-Server负责接收SQL请求，处理SQL相关的逻辑，是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，TiDB-Server有三个后台功能，垃圾回收（GC）、执行DDL、管理统计信息。

5.TiDB-Server是否可以应用到OLAP场景？

答：在OLAP场景中进行大表Join时，通常会占用较多的内存存储中间数据，不建议将TiDB-Server用于替代离线数仓或者大数据产品。

6.TiKV数据文件如何存储？

答：TiKV分布式Key-Value存储引擎是全局有序的，每一个表会分配TablelD，TablelD与每行的Primary Key共同构成Key-Value中的Key，通过具体的Key定位该行数据。数据按照Region进行分片存储，Region是一个左闭右开区间，边界是StartKey到EndKey，TiKV会上报分片Region的数据分布到PD进行管理，Region分片不需要分片键，不侵入业务，采用动态分片技术，分片可以自动分裂及合并。

7.TiKV使用什么存储结构？

答：采用了LSM-tree作为存储结构，这是一种使用空间来置换写入延迟（非原地更新）的数据结构，它采用的是顺序写入的方式。

8.TiDB的启动和关闭顺序？

答：启动PD->TiKV->TiDB-Server->TiFlash；关闭TiFlash->TiDB-Server->TiKV->PD。

9.TiDB数据库不支持哪些MySQL特性？

答：外键、存储过程、自定义函数等。

10.两地三中心容灾方案使用什么协议？

答：使用Raft协议（多数派一致协议），TiDB数据库两地三中心支持数据丢失（RPO）为0，服务恢复（RTO）约为30秒，用于节点投票。

11.TiDB数据库如果实现分布式SQL计算？

答：SQL的部分计算通过存储节点的Coprossesor组件下推到到TiKV进行条件过滤等计算。

12.TiDB数据库的扩展性基于什么实现？

答：TiDB基于Region实现灵活的扩展性，Region是复制、调度的最小单元，它是左闭右开的存储单元，它支持自动分裂分片及合并，通过PD的元数据管理，分片查询成本不会因为节点的增多而变大。

13.TiDB数据库实现跨IDC机房场景时Region复制基于哪种机制？

答：分片Region的复制基于Multi-Raft机制，可以支持多活，即单个表可以从多个IDC读和写，可以通过标签分组实现机房、机柜等维度的打散。

14.TiDB数据库采用哪种事物模型？

答：采用Percolater事物模型，默认隔离级别为Snapshot Isolation，由TiKV存储引擎实现事务，支持多个节点参与的分布式事务能力。

15.TiDB数据库的HTAP能力包括哪些？

答：HTAP的AP部署包括可实时写入更新的列式存储TiFlash、Spark运行于TiKV之上、列式存储TiFlash支持MPP并行计算和计算能力扩展。

16.TiFlash组件采用哪种数据结构？

答：列式存储引擎TiFlash采用Delta tree数据结构支持准实时更新。

17.TiFlash组件是否具备大规模并行计算（MPP）能力？

答：列式存储TiFlash的MPP能力可以将任务并行地分散到多个服务器和节点上，由优化器进行判断是否使用MPP，通过MPP可以实现一条Join语句在多个TiFlash节点并行执行。

18.TiFlash如何接入TiKV？

答：TiFlash以Raft Learner方式接入Multi-Raft组，Learner身份只从TiKV复制数据，不参与投票，同步到TiFlash后会被从行格式拆解为列格式，通过读取标签标识同步进度，实现一致性读取。

19.TiSpark组件的功能有哪些？

答：TiSpark将Spark计算能力引入TiDB 生态，Spark可以识别和读取TiKV的数据格式、统计信息等，它支持低并发的重量级查询、报表、重量级  Adhoc即席查询，但是它不支持高并发。

20.Tiup开始于TiDB哪个版本？有哪些功能？

答：Tiup 是从4.0 开始引入的集群管理工具，既可以管理内核组件（PD、TiKV、TiDB、TiFlash），也可以管理工具组件（DM、TiCDC 和 TiDB Binlog），实现完整的集群生命周期管理功能可以部署、管理（启停、修改参数）、升级、销毁。

21.如何使用tiup查看群集状态？

答：tiup cluster list查看环境中的集群列表，tiup cluster display查看集群中各个节点的运行状态。tiup cluster deploy部署TiDB数据库。

22.TiDB数据库如何扩容、缩容？

答：使用tiup cluster scale-out扩容，使用tiup cluster scale-in 缩容支持业务在线进行操作，PD、TiKV、TiDB方法一致，因为TiFlash的副本是配置在字典内的，需要先增加和删除所有表的TiFlash 副本，再进行扩容或者缩容。

23.TiDB数据库群集配置如何修改？

答：集群配置存储在配置文件中，所有节点都有配置文件，使用 tiup cluster edit-config 进行编辑并下发配置文件给各个节点，修改后需要重启节点生效。

24.TiDB数据库的系统参数如何修改，是否有作用域？

答：TiDB数据库的系统参数持久化在TiKV存储中，分为全局、会话和 Instance 作用域，set global 将全局作用域的系统参数修改后只会影响新建立的连接，不会影响当前的执行修改命令的连接和其他已有的连接；alter session只能修改当前会话参数，不会影响其他连接和新连接参数。

25.TiDB数据库的升级顺序？

答：升级Tiup-->修改群集拓扑文件-->检查当前群集健康状态-->使用tiup升级到指定版本-->验证并检查当前群集健康状态。

26.TiDB数据库的监控体系有哪些？

答：TiDB数据库的监控体系，Prometheus 是监控数据存储，Grafana 用于图形化展示，Alertmanager用于实现报警机制，都需要额外的服务器进行部署，在现实中它们通常被部署在一起，Prometheus+Grafana监控页面可以查看Region的状态，包括Regions的数量和是否有错误的Region。TiDB Dashboard 是集群的管理平台，它集成在PD Server中，无需独立部署，Dashboard支持所有SQL查询的耗时等执行信息、组件及主机运行状态、收集分析各个组件的性能数据、诊断常见集群问题并生成报告、集群读写流量分布及趋势变化，列出所有SQL查询的耗时等执行信息，详细了解耗时较长的SQL语句的功能 。

27.TiDB数据库用户和角色的区别？

答：TiDB数据库支持基于角色的访问控制，角色和用户信息都存储在mysql.user 表中，角色没有密码，创建角色时如果省略主机名默认为‘%’，用户在登录时，默认启用的角色会被自动启用，角色可以被赋予给角色或者用户。

28.TiDB数据库认证与授权的区别？

答：用户连接TiDB数据库一般是先认证后进行授权，认证失败则无法连接数据库，授权操作失败则操作会报错。

29.TiDB数据库有哪几种备份方式？

答：TiDB的备份方式如下表，热备份允许读写数据，温备份只允许读取数据但是无法修改数据，冷备份（操作系统拷贝）不允许读取数据或者修改数据。

方法冷/热/温备份逻辑备份/物理备份一致性BR工具热备物理备份是Dumpling热、温备份逻辑备份是复制热备逻辑备份是操作系统备份冷备物理备份是

30.BR备份工具的有哪些特点？

答：BR备份工具属于物理备份，数据由TiKV从各个Region的leader生成SST格式的KV数据，它是专用的TiDB格式，不能用于MySQL的还原。TiKV进行数据还原时，没有固定的节点对应关系，所有的节点都需要访问完整的数据，所以BR最好使用NFS/S3共享存储存储。BR工具的适用场景包括快速备份全量数据或者增量备份、备份数据量较大(TB级别)的库、要求校验备份数据。BR工具ratelimit参数可以用来限制单个TiKV节点执行备份的最大速率，br restore命令用于执行恢复任务，恢复时需要所有的TiKV节点都能读到全部备份数据。

31.Dumpling备份工具有哪些特点使用场景有哪些？

答：Dumpling工具支持TiDB的逻辑备份，它的速度较慢，备份的SQL文件（由一系列SQL语句组件）既可以用于TiDB也可以兼容MySQL数据库，需要恢复到MySQL的表数据级规模较小（千万或者以下），可以还原数据库备份时的状态。

32.Lightning工具使用场景？

答：Lightning是数据导入工具，它支持CSV和SQL文件，支持选择只导入某个SCHEMA或者全部的数据，支持断点续传功能并可将断点存储在其他数据库中。Local-backend方式仅支持高版本，TiDB-backend方式支持全部TiDB版本，TiDB-backend后端模式实际是使用insert语句进行插入，也仅TiDB-backend模式支持同时进行写入。

33.TiDB数据库有哪些同步工具？

答：TiDB Data Migration（TiDB DM）、TiDB Binlog、TiDB TiCDC。

34.TiDB DM的使用场景及使用方法说明？

答：DM是MySQL到TiDB的复制工具，从MySQL数据库全量数据和增量数据到TiDB数据库，DM可以支持单个源库上游的表复制到TiDB，也支持多个上游源库的表复制合并到TiDB单表，支持同步部分库和表的，但不支持选择同步表的部分列，下游表的列可以多于上游表的列；DM通过tiup部署，分为Master集群管理组件和worker工作组件，和dmctl管理工具，源库(上游)实例的从库worker为bound状态，worker与源库是1对1的关系，worker 多于源库实例时，未绑定的worker状态为free；DM集群节点查看命令是tiup dm display dm-name，DM复制任务状态的启动命令是tiup dmctl --master-addr ip:port start-task task.yamlDM复制任务状态的查看（含出错原因）是tiup dmctl --master-addr ip:port query-status task-name；DM的任务配置文件中，task-mode:“all” 表示同步全量数据和增量数据，Block & Allow Table Lists 用于限定 DM 的表清单范围，Table routings 用于支持多个上游源库的表复制合并，Binlog event filter 用于过滤某些操作。

35.TiDB Binlog的使用场景及使用说明？

答：TiDB Binlog的适用场景包括源库(上游)为TiDB 数据库，目标库(下游)为MySQL或者Kafka的复制场景，它不支持实时同步复制；TiDB Binlog是提交时进行写入的，未提交的事务是不会出现在Binlog中，Binlog按照事务提交的时间戳顺序进行排序，Binlog记录的是每一行数据的变更；TiDB Binlog分为Pump和Drainer，Pump组件可以部署多个形成集群，具备高可用和水平扩展能力，一个Drainer仅对应一个写入目标，不具备高可用性。

36.TiCDC的使用场景及使用说明？

答：TiCDC集群支持多个同步任务，它的Capture接收绑定的changefeed所包含的表所在的TiKV的KV Change Data并进行排序;TiCDC复制工具可以支持目标库是TiDB或者 Kafka，具备高可用特性，可以实现自动故障转移功能，以TiKV作为数据源并且输出change data；TiCDC 复制工具可以支持多个任务，但是更新同步任务需要修改后再操作（不支持动态调整），创建 changefeed 时，changefeed-id 可以由系统自动分配，默认支持目标端(下游)的数据同步的并行同步方式。

37.TiCDC和TiDB Binlog相同点和区别？

答：TiCDC和TiDB Binlog都可以支持下游是TiDB/MySQL/Kafka，都可以在TiDB 5.0.0上使用（Binlog不兼容TiDB 5.0的一些新特性）。TiCDC集群具有高可用性，TiDB Binlog的Drainer 不具备高可用性，TiCDC数据源都是TiKV的KV Change Data，TiDB Binlog数据源是TiDB的事务写入KV。