TiDB In Action故障排查指南解决热点问题和TiKV繁忙的终极方案【免费下载链接】tidb-in-actionTiDB In Action: based on 4.0项目地址: https://gitcode.com/gh_mirrors/ti/tidb-in-actionTiDB作为一款分布式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问题否则可能是小表的大量并发读取导致。针对读热点有以下解决方案优化慢SQL通过执行计划分析和索引优化减少不必要的全表扫描和低效查询增加Block Cache大小通过调整TiKV配置增加Block Cache容量提高热点数据缓存命中率使用Follower ReadTiDB 3.1及以上版本提供的Follower Read功能可将读请求分散到 follower 节点增加集群读吞吐能力表结构优化对于频繁访问的小表可考虑改造成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的热点调度策略PDPlacement 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-1TiKV繁忙问题全面解决方案TiKV繁忙的常见原因分析TiKV节点出现server is busy错误通常意味着该节点资源紧张无法及时处理请求。常见原因包括热点写入/写入倾斜磁盘I/O压力过大内存不足RocksDB Compaction压力通过观察监控指标如Raftstore通道是否满、scheduler是否繁忙等可以初步判断TiKV繁忙的原因。磁盘I/O压力过大的优化方案磁盘I/O是TiKV性能的关键瓶颈之一。当磁盘I/O压力过大时可采取以下措施使用高性能存储将TiKV数据目录迁移到NVMe SSD等高性能存储设备调整RocksDB参数优化RocksDB的Compaction策略如调整level0_file_num_compaction_trigger、max_compaction_bytes等参数分散I/O压力将不同TiKV实例的数据目录分布在不同的物理磁盘上内存不足问题的解决方法内存不足会导致TiKV频繁进行磁盘交换严重影响性能。解决方法包括增加系统内存为TiKV节点配置更多的物理内存优化Block Cache设置合理配置Block Cache大小在内存使用和缓存命中率之间取得平衡调整GC策略优化TiDB的GC垃圾回收策略避免大量过期数据占用内存RocksDB Compaction压力的缓解策略RocksDB的Compaction操作会消耗大量系统资源导致TiKV繁忙。可通过以下方法缓解调整Compaction线程数通过rocksdb.max-background-compactions参数增加Compaction线程数优化Compaction配置调整level0_slowdown_writes_trigger、level0_stop_writes_trigger等参数避免Write Stall使用Titan插件对于写入量大的场景可启用Titan插件减少RocksDB的Compaction压力综合案例热点和TiKV繁忙问题的实战解决案例背景某核心业务有两个表业务数据表A和流水表B。表A和B都使用字符型主键加时间索引导致数据本身和时间索引都成为热点引发TiKV节点繁忙。解决方案表结构改造对表A的主键进行改造将原主键的一部分转换为bigint类型并在最前面添加1位0-9的随机数人为将数据分成10片索引优化对时间索引采用分区表策略按时间范围将数据分散到不同RegionPD调度优化调整PD的热点调度参数提高热点调度速度资源隔离将热点表的数据迁移到性能更高的TiKV节点通过以上综合措施成功解决了热点和TiKV繁忙问题系统性能提升了3倍以上。总结与最佳实践TiDB的热点问题和TiKV繁忙是常见的性能瓶颈但通过合理的表结构设计、参数优化和调度策略可以有效避免和解决这些问题。以下是一些最佳实践建议表设计阶段避免使用自增主键合理设置SHARD_ROW_ID_BITS和PRE_SPLIT_REGIONS监控体系建立完善的监控告警体系及时发现热点和TiKV繁忙问题定期维护定期分析慢SQL优化索引调整PD调度策略容量规划根据业务增长趋势提前进行容量规划和资源扩展通过本文介绍的方法和策略你可以系统地排查和解决TiDB的热点问题和TiKV繁忙现象确保集群始终处于最佳运行状态。如需更深入的了解可参考TiDB官方文档中的性能优化章节。【免费下载链接】tidb-in-actionTiDB In Action: based on 4.0项目地址: https://gitcode.com/gh_mirrors/ti/tidb-in-action创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考