一个好的问题描述有利于社区小伙伴更快帮你定位到问题，高效解决你的问题
【TiDB 使用环境】生产环境
【TiDB 版本】v8.5.7
【部署方式】物理机部署
【操作系统 / CPU 架构 / 芯片详情】CentOS 7.9 x86_64
【机器部署详情】TiKV 节点：16 核 / 64G 内存 / SAS SSD
【集群数据量】总数据量 2.2TB，目标大表约 650GB
【集群节点数】TiDB Server×4，PD×3，TiKV×8，TiFlash×3
问题描述
业务执行批量 UPDATE 更新大表部分分区数据后，监控发现：
- 部分 TiKV Region CPU、QPS 突增，出现持续读写热点，业务 SQL 响应超时；
- 同表 TiFlash 副本同步延迟持续上涨，超过 30min，AP 报表查询数据不一致；
- 临时限流后热点有所缓解，但只要再次执行批量 DML，问题复现。
已做操作：
- 调整
tidb_distsql_scan_concurrency 降低并发；
- 手动 split 热点 Region，短期生效，很快再次汇聚热点。
疑问
- 批量 DML 造成 Region 热点和 TiFlash 同步延迟存在关联吗？完整排查链路是什么？
- 除手动分裂 Region 外，有哪些长效优化方案（SQL 改造、参数、索引、数据分布策略）？
- TiFlash 同步阻塞的常见根因和应急止血手段有哪些？
期待建议
希望能分享完整排查思路、重点监控指标、参数调优建议以及业务侧规范，区分应急处理和长期架构优化方案。
深圳小强
(ZGY)
2
针对上述问题做如下分析和建议，仅供参考
–原因分析
批量修改连续区间数据，写入集中单Region，产生大量Raft日志，同时引发TiKV热点、TiFlash同步队列积压
–临时方案
1、拆分大事务，降低批量更新并发
2、热点Region执行split打散
3、非实时AP场景可临时移除该表TiFlash副本
–长期方案
1、业务分批更新，连续主键表开启’SHARD_ROW_ID’打散数据
2、通过Resource Control限制批量DML资源优先级
3、高频变更表评估是否需要TiFlash副本，做架构取舍
–指标监控
TiKV Region流量、Leader分布,TiFlash同步lag
1 个赞
kang
4
从现象看，批量UPDATE大表确实容易引发双链路问题，两者强关联。核心链路是：批量DML产生大量写流量→TiKV热点Region写入瓶颈→Raft日志同步变慢→TiFlash通过Raft Learner同步也受影响，延迟自然飙升。
批量高频改同一分区，Region 会打热，TiFlash 也要消化同样写入，延迟会一起涨。先限流、拆小事务、按主键打散；看 TiKV busy、write stall 和 TiFlash replay。手动 split 只是止痛，长期改写入模式、索引和分区键，避免反复打同一段。
system
(system)
关闭
6
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。