谢谢，这个safe update 参数我们有用，现在是想进别区分隔离变更入口和只读入口。

感谢，中间件这个是一个思路~不过有点重度。。还不如创建一个只读账户了

感谢大家的建议，但这就是为了挡住 DBA 自己 Commandline 误操作呢，这和开放只读查询给 dev 同学查询，那就就不是一个场景了哦。

不是姿势不对，现在就是没找到姿势 TiDB 没有优雅实现这个呀

DM 踩得特别多，反倒是 CDC 没有踩过什么深大坑，反倒是有个比较渴望的需求趁机提一下 考虑一下原生支持流量压缩，因为我们的场景是主要把 TiCDC 用在了异地灾备同步，流量费贵呀，现在是再前面顶了个 proxySQL 来做转发实现流量压缩~

冲冲冲！盘它！

对这我知道。但我们这里不想开这个。。。

好问题，不是 100%确定，但觉得应该能吧：前序事务invalid connection 失败，在单线程模式，难度不重试就直接应用下面的事务了吗？

666 期待直播了解

请问晚了一些，还可以参加上吗、、、我是12 号 17:00 之后才回复 GITHUB ID 的，然后昨天才提的 PR。。。

感谢提醒。经过确认，我们的业务系统确实使用了自动提交策略（也就是说确实是默认使用了乐观事务），在 TiDB 日志中也的确发现存在大量的事务重试日志。 但进一步排查发现，出现重试的语句，与业务反馈的 INSERT 慢语句所涉及的表，并不是同一批表。 目前这个问题仍然未明确。但我觉得你这个回答是最具有明确且具体的提示排查方向作用，感谢提醒。

悲观模式来的。大家都提到这个减少并发，我没理解，是怎么影响到的这个问题的，平时业务一直是高并发写入的，现在是偶发出现的，找不到其他问题迹象，也没定位到性能瓶颈点。

您问的 insert 类型指的是？这个表只有两个索引，一个是是主键（聚簇索引），还有一个业务上用的唯一索引。

目前并没有定位到明显的 CPU、内存、磁盘 IO 资源瓶颈点，这个问题比较诡异。要说是锁冲突等待，也跟业务确认过，事发时不存在并发的重复插入

感谢文杰大佬支持。最主要是业务没有特别的变化，日常一直都是这么并发插入的，就是有那么一些时间会存在这种问题

热点读写排除过了，当时不存在突发热点读写迹象

（我是这个issue 楼主的同事）补充一下目前怀疑的点和情况： mysql.gc_delete_range 这个表里面，从 0908 就开始长期残留几个 ranges 了，对比其他新的 ranges 差异明显， [image] 从近一个月的 delete日志也发现一直 delete 这些 ranges 都是失败的： [image]

同问，希望不是知道得太迟