作者：李少卿
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。
