TiDB面试题以及如何阐述为什么要用TiDB - 抬头看月亮の小猫猫 (moonxy.cn)

为什么要使用TiDB？

使用TiDB的原因主要有以下几点：

• 在MySQL层面通过分库分表的方式，拆分出来，但这对业务和 DBA 来说都是不小的工作量，最痛苦的无异于这些大表的改变；
• 无论是单表上 T，还是分库分表，对一张大表执行 DDL 的代价是非常大的；
• 针对业务爆发式增长的数据量，我们开始调研选型是否有其他数据库可以代替传统的 MySQL；
• 通过调研我们了解到 TiDB，迁移平滑，基本上无需业务变动代码，完全的事务 ACID 支持，分布式的架构，自带高可用、OnlineDDL；
• TiDB 在公司集团引入的最早时间是2018年中旬，数据仓储前期评估数据量规模在亿级别以下，不需要直接使用TiDB来存储；
• TiDB 百分之九十九兼容 MySQL 协议，在数据层面业务、开发几乎不用做任何大的代码改动；
• 我们的业务量暴增，数据太大，想寻求一种在存储层只需要加节点就搞定，不想改造更多的业务代码；
• 我们业务本身是查询统计这块的业务场景比较多，正好TiDB对于OLAP的支撑很好！
• 在一些复杂的BI统计需求下，TiDB的查询性能比MySQL更优秀；
• 前期的好几套业务系统已经基于我们的仓储数据开发了相关的三方业务，如果数据仓库数据结构这块的改动涉及到多方的改动，改造成本太高；

TiDB 的存在是为了解决什么问题？

• 重点解决MySQL 的单机性能和容量无法线性和灵活扩展的问题；
• 兼容MySQL协议（对于原始业务SQL无需做改造）；
• 可在线扩展（数据分片支持分裂和自动迁移，对业务使用方来说无感知）；
• 强一致的分布式事务保证（支持跨节点、跨分片的分布式事务，并且事务保证强一致）；
• 支持MySQL二级索引；
• 支持OLAP+OLTP场景；
• 跨机房高可用，任何一个机房挂掉，服务自动切换；
• 支持海量数据存储，不需要在业务层做分库分表，TiDB自身底层支持，业务使用人员关注业务即可，数据 Sharding
  的事情交给TiDB来做，数据爆发增长，只需要增加 TiKV 节点即可，TiDB本身支持数据的自动均衡；

TiDB 的原理以及架构是怎样的？

架构图
MySQL的一些集群方案和数据库中间件都在试图解决当表条目变大时，查询性能会出现严重下降的问题。TiDB的这套架构适用于大规模数据量的存储和查询，重点关注以下几个核心组件：

PD

• 保存数据库中的逻辑表到真实TiKV节点中数据分布的关系；
• 负责对TiKV集群做调度和负载均衡；
• 分配全局事务ID;
• 负责TiDB集群的元信息数据管理；

TiDB

• 负责接收SQL检查、语法解析；
• 从原始SQL到逻辑查询的转换；
• 借助PD将逻辑查询转换为物理查询；
• 从TiKV节点查询数据后加工、计算并返回；

TiKV

• 分布式KV存储引擎；

使用TiDB的过程中遇到了那些问题，如何解决？

问题1：TiDB线上报 "pd server timeout"

处理：业务测在代码中加上相关超时重试的处理，将 TiDB 机器上 min_free_kbytes 从默认的 66M 调成 512M，留更多内存给内核用。

问题2：TIDB 生产环境发生 OOM问题。

处理方案1：将OLAP频繁的SQL业务放到一个单独的TiDB集群，与现有的一套TiDB集群进行隔离，防止一个业务的OLAP SQL 影响到其他的业务；

处理方案2：oom-action 配置为 cancel，kill 使用内存超过阈值的 SQL，单条SQL使用的内存阈值调整配置文件；

问题3：TiDB线上内存使用过大

处理：抓取内存 profile 分析，怀疑是 TiDB 2.1.8 版本一个 goroutine 泄漏的 bug 引起，后面通过升级TiDB版本到2.1.11 版本。

问题4：TiKV 热点问题，region 分布不均匀

处理：某一个周末发现有3台TiKV的CPU使用率均达到100%，最终定位到原因为PD各个调度器抢占的问题，升级TiDB版本到2.1.11 版本。

问题5：重启TiKV调整参数，业务侧出现"tikv timeout"的异常

处理：由于强制关闭了tikv集群，造成region 的自动选主，"tikv timeout"属于正常现象。

问题6：Pd Server Timeout

处理：etcd bug引起。TiDB已经向etcd开发提出issue，等待回复及改进。issue地址：https://github.com/etcd-io/etcd/issues/10713

问题7：tidb 实例频繁重启

处理：txn-latch-local 是一个关于事务内存锁，缓解事务冲突的功能，这个功能在 tidb 产品后续优化了事务的并发且引入了悲观锁机制之后，已经不再维护了。需要关闭 txn-local-latch ，即设置 txn-local-latch = false

问题8：tidb实例网卡流量巨大20Gbps 持续将网卡打满

处理：改写sql 逻辑，调整每次拉取的记录大小；

问题9：tidb 某些 sql 会出现索引失效
处理：对于发现失效的SQL，使用HINT这种方式强制指定索引解决。

问题10：tidb用户权限问题只有增删改查权限却可以truncate表

处理：truncate权限未做好隔离,问题在2.1.7版本中进行了修复