【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】4.0.10
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】insert慢，业务写入sql是insert on duplkicate key 批量写
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
可以先发下表结构，索引
分析下呗，看下 tikv-detail raft-io 部分
看看表上的索引是否特别多，或者是否有位图索引
怀疑是有热点，可以做一下shard_rowid_bits试试。
https://docs.pingcap.com/zh/tidb/v7.5/troubleshoot-hot-spot-issues#tidb-热点问题处理
v4.0可以看看这个系列
那个热点分析监控图看下
1 个赞
确认是否所有写入操作都集中在表的某一部分。
例如，如果表有一个自增主键，且写入总是追加到表的末尾，就容易形成热点。
调整写入策略，如果可能，尝试改变写入模式。
例如，使用散列（hash）分片主键，或者在写入时添加一些随机性，以分散写入负载。
可以参考下：
1.索引的问题：
查看索引数量和类型：使用SHOW INDEX FROM table_name语句查看表上的索引信息，评估索引是否过多或是否存在不必要的索引。对于非必要的索引，可以考虑删除以提高写入性能。 通过EXPLAIN语句分析insert on duplicate key语句的执行计划，查看索引是否被有效利用，以及是否存在全表扫描等低效操作。检查碎片的变化，可以通过观察索引的大小变化、查询性能变化，如果有就 ANALYZE TABLE命令来收集统计信息并优化查询计划。
2.观察状态：
监控事务大小和执行时间，如果发现事务过大，可以考虑将批量写入拆分成多个较小的事务，以降低事务日志的大小和事务处理的开销。检查并发冲突，或者调整 TiDB 的并发控制参数tidb_txn_mode等一些参数，需谨慎。
推荐还是先打散热点，
可以先看下监控 tikv-detail >> thread cpu 里面的 cpu 使用分布情况。
集中在一个region的写，推测是热点问题，可以结合tidb Dashboard和tikv details面板的资源使用的情况进一步判断，确认后可以根据官网的建议打散热点