企业官网建设流程全解析

TiDB In Action故障排查指南：解决热点问题和TiKV繁忙的终极方案

【免费下载链接】tidb-in-actionTiDB In Action: based on 4.0项目地址: https://gitcode.com/gh_mirrors/ti/tidb-in-action

TiDB作为一款分布式NewSQL数据库，在处理大规模数据和高并发场景时展现出强大的能力。然而，随着业务复杂度的提升，热点问题和TiKV繁忙现象可能成为性能瓶颈。本文将提供一套完整的故障排查流程和解决方案，帮助你快速定位并解决这些常见问题，确保TiDB集群稳定高效运行。

热点问题深度解析与解决策略

如何快速确认TiDB热点问题？

在分布式数据库中，热点问题会导致单个节点成为资源瓶颈，严重影响整个系统的吞吐能力。当初步怀疑集群存在热点问题时，可通过TiDB Grafana提供的TiKV-Trouble-Shooting Dashboard的Hot Read和Hot Write面板进行快速确认。

Hot Read面板聚集了读取热点相关的核心指标，包括各TiKV节点的读请求数、读吞吐量等；Hot Write面板则展示写热点相关指标。通过观察是否存在个别TiKV节点的指标明显高于其他节点，可以快速判断集群是否存在读热点或者写热点。

定位热点表和索引的实用方法

确定是个别TiKV实例的热点问题后，需要进一步确认具体是哪张表或哪个索引导致的热点。从TiDB 3.0开始，推荐通过SQL查询information_schema.TIDB_HOT_REGIONS表定位热点：

SELECT * FROM information_schema.TIDB_HOT_REGIONS WHERE TYPE = 'write';

该查询结果将显示热点类型、涉及的表名、索引名以及热点程度等关键信息。如果热点现场已过，可以通过业务监控提取问题表和问题SQL。TiDB 4.0及以上版本提供的Key Visualizer功能，能直观展示整个数据库的不同位置数据访问频度和流量，帮助快速定位热点。

读热点解决方案：从缓存到架构优化

TiDB读取热点通常源于TiKV的BlockCache命中率下降或小表的并发读取过大。可通过检查TiKV-Details Dashboard里RocksDB KV面板的Block cache hit命中率来判断：

如果命中率出现大幅度下降或抖动，基本可以定位为慢SQL问题；否则可能是小表的大量并发读取导致。针对读热点，有以下解决方案：

1. 优化慢SQL：通过执行计划分析和索引优化，减少不必要的全表扫描和低效查询
2. 增加Block Cache大小：通过调整TiKV配置，增加Block Cache容量，提高热点数据缓存命中率
3. 使用Follower Read：TiDB 3.1及以上版本提供的Follower Read功能可将读请求分散到 follower 节点，增加集群读吞吐能力
4. 表结构优化：对于频繁访问的小表，可考虑改造成hash表，将数据分散到多个Region

写热点解决方案：从表设计到调度策略

TiDB写入热点的业务场景通常包括：使用自增主键、无主键表、小表高并发更新、单调递增索引以及秒杀等特殊场景。以下是针对性的解决方案：

自增主键导致的热点问题

MySQL为提高顺序写入性能通常建议使用自增ID作为主键，但在TiDB中，自增主键会导致数据集中写入单个Region，引起热点。解决方法是：

CREATE TABLE t ( id INT, name VARCHAR(20), PRIMARY KEY (id) ) SHARD_ROW_ID_BITS = 4 PRE_SPLIT_REGIONS = 16;

SHARD_ROW_ID_BITS用于将行ID随机打散，PRE_SPLIT_REGIONS在建表后预先进行Region拆分。

无主键表的热点问题

当表没有主键或主键不是int类型时，TiDB会自动生成隐式的_tidb_rowid列，该列值单调递增，导致大量INSERT时数据集中写入单个Region。解决方案同上，使用SHARD_ROW_ID_BITS和PRE_SPLIT_REGIONS建表选项。

秒杀等单行热点场景

秒杀减库存等单行热点更新场景下，大量请求并发更新同一行记录，推荐调整为TiDB的悲观锁。对于这类极端场景，建议通过异步队列或缓存来削峰，也可考虑通过弹性调度将热点隔离到高性能机器。

调整PD的热点调度策略

PD（Placement Driver）的热点调度策略可作为热点问题解决方案的补充。对于写热点，PD会尝试打散热点Region的Peer和Leader；对于读热点，会尝试将热点Region的Leader打散。关键优化参数包括：

• hot-region-schedule-limit：控制热点调度的并发度
• hot-region-cache-hits-threshold：调整PD对流量变化的响应速度

在业务低峰期，可添加scatter-range-scheduler调度器使表的所有Region均匀分布：

tiup ctl pd -u http://pd-ip:2379 scheduler add scatter-range-scheduler table-1

TiKV繁忙问题全面解决方案

TiKV繁忙的常见原因分析

TiKV节点出现"server is busy"错误通常意味着该节点资源紧张，无法及时处理请求。常见原因包括：

1. 热点写入/写入倾斜
2. 磁盘I/O压力过大
3. 内存不足
4. RocksDB Compaction压力

通过观察监控指标，如Raftstore通道是否满、scheduler是否繁忙等，可以初步判断TiKV繁忙的原因。

磁盘I/O压力过大的优化方案

磁盘I/O是TiKV性能的关键瓶颈之一。当磁盘I/O压力过大时，可采取以下措施：

1. 使用高性能存储：将TiKV数据目录迁移到NVMe SSD等高性能存储设备
2. 调整RocksDB参数：优化RocksDB的Compaction策略，如调整level0_file_num_compaction_trigger、max_compaction_bytes等参数
3. 分散I/O压力：将不同TiKV实例的数据目录分布在不同的物理磁盘上

内存不足问题的解决方法

内存不足会导致TiKV频繁进行磁盘交换，严重影响性能。解决方法包括：

1. 增加系统内存：为TiKV节点配置更多的物理内存
2. 优化Block Cache设置：合理配置Block Cache大小，在内存使用和缓存命中率之间取得平衡
3. 调整GC策略：优化TiDB的GC（垃圾回收）策略，避免大量过期数据占用内存

RocksDB Compaction压力的缓解策略

RocksDB的Compaction操作会消耗大量系统资源，导致TiKV繁忙。可通过以下方法缓解：

1. 调整Compaction线程数：通过rocksdb.max-background-compactions参数增加Compaction线程数
2. 优化Compaction配置：调整level0_slowdown_writes_trigger、level0_stop_writes_trigger等参数，避免Write Stall
3. 使用Titan插件：对于写入量大的场景，可启用Titan插件，减少RocksDB的Compaction压力

综合案例：热点和TiKV繁忙问题的实战解决

案例背景

某核心业务有两个表：业务数据表A和流水表B。表A和B都使用字符型主键加时间索引，导致数据本身和时间索引都成为热点，引发TiKV节点繁忙。

解决方案

1. 表结构改造：对表A的主键进行改造，将原主键的一部分转换为bigint类型，并在最前面添加1位0-9的随机数，人为将数据分成10片
2. 索引优化：对时间索引采用分区表策略，按时间范围将数据分散到不同Region
3. PD调度优化：调整PD的热点调度参数，提高热点调度速度
4. 资源隔离：将热点表的数据迁移到性能更高的TiKV节点

通过以上综合措施，成功解决了热点和TiKV繁忙问题，系统性能提升了3倍以上。

总结与最佳实践

TiDB的热点问题和TiKV繁忙是常见的性能瓶颈，但通过合理的表结构设计、参数优化和调度策略，可以有效避免和解决这些问题。以下是一些最佳实践建议：

1. 表设计阶段：避免使用自增主键，合理设置SHARD_ROW_ID_BITS和PRE_SPLIT_REGIONS
2. 监控体系：建立完善的监控告警体系，及时发现热点和TiKV繁忙问题
3. 定期维护：定期分析慢SQL，优化索引，调整PD调度策略
4. 容量规划：根据业务增长趋势，提前进行容量规划和资源扩展

通过本文介绍的方法和策略，你可以系统地排查和解决TiDB的热点问题和TiKV繁忙现象，确保集群始终处于最佳运行状态。如需更深入的了解，可参考TiDB官方文档中的性能优化章节。

【免费下载链接】tidb-in-actionTiDB In Action: based on 4.0项目地址: https://gitcode.com/gh_mirrors/ti/tidb-in-action