TiKV_scheduler_latch_wait_duration_seconds频繁报警排查是因为mysql.stats_meta频繁出现scheduler handle command: acquire_pessimistic_lock的问题，请问这个怎么解决

[du拉松]

【 TiDB 使用环境】生产环境
【 TiDB 版本】v4.0.13
【复现路径】没有做特殊操作
【遇到的问题：问题现象及影响】最近钉钉经常出现TiKV_scheduler_latch_wait_duration_seconds的报警，type为：acquire_pessimistic_lock，查看报警对应的tikv节点，报警时刻会出现很多[WARN] [process.rs:190] [“[region 87471540] scheduler handle command: acquire_pessimistic_lock, ts: 442795953110646803”] [takes=1197]相关日志。
根据regionId查询对应的表为：mysql.stats_meta。sql为：select region_id,table_name,db_name from TIKV_REGION_status where region_id = ‘87471540’;
请问这种问题怎么解决？
【资源配置】
【附件：截图/日志/监控】

[有猫万事足]

疑似这个issue
https://github.com/pingcap/tidb/issues/25659

4.0.13版本发布正好在这个bug时间之前。
https://github.com/pingcap/tidb/tree/v4.0.13

[redgame (Ti D Ber Pa Amoi Ul)]

确保没有长时间运行的事务持有 mysql.stats_meta 表的锁。可以检查 TiDB 中是否有未提交或者长时间运行的事务，并尽快完成或终止这些事务

[du拉松]

嗯嗯，感觉是这种问题。但是这种除了升级对应的版本来解决外还能怎么解决呢？split region是否可以减少该问题产生呢？

[du拉松]

从慢查询中可以看到很多相关更新该表的操作，但是这些都是数据库自己的更新吧，从慢sql的执行计划中可以看到，花的时间都是在lock_keys上。

[有猫万事足]

如果是bug的话，不升级很难解决，更何况还是系统表的时候出的问题。改造业务也没有办法规避。

[xfworld (魔幻之翼)]

该升级的时候，就升级啊~