某日无事，想看看数据库的业务和性能方面有没有潜在问题，通过TiDB的INFORMATION_SCHEMA数据库SLOW_QUERY表，发现了大量INSERT INTO的慢日志,执行时间在0.3-1.5s之间，平均每几秒钟就有一条。

虽然这个表的数据量很大，但是一般业务情况，一个简单的INSERT INTO操作是不会这么慢的，而且不会这么频繁。

第一阶段： 反馈给公司TiDB团队，被告知有INSERT INTO SQL执行报错日志，是因为一个字段内容超过了限定的长度。修复这个问题，发上线观察，慢日志问题并没有解决

第二阶段: TiDB团队排查结果：该数据库节点内存占用太高，将内存降下来后，不再每秒都有slow log记录，但是会一段时间出现几分钟连续的slow log情况，观察是磁盘IO达到阈值，将阈值由60%调整到80%，继续观察， 当 region score 这个检测带你，突然高峰，某时刻波动又进行分配时，在这积分钟时间又会有大量延迟产生，并且此时执行时间变成10s-20s，这个情况每隔几小时会出现一次，一天大概3-4次。这么长时间的延迟，心里还是不能接受啊，继续反馈。

第三阶段: 该节点主机的磁盘IO率不高，但比其他节点主机高不少，从该节点主机上迁移走别的库的kv节点，磁盘IO率降低，观察几天，INSERT 的SLOW_QUERY 记录几乎不再出现，SELECT的慢日志数量也降低

现阶段：仍有INSERT的SLOW LOG，每天大概在30条左右，执行时间是在0.3-1.5s之间,观察TiDB监控图的延迟信息，不会有急剧的高峰