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]

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

感谢支持~~ 今天发现原来不是 emoji 的问题，是我们导入这些数据里面，有几个无法识别的 utf8 coding： \ufffd，具体来说就是这个� ，导致触发了 tidb 的 utf8 check，其实并非不支持 emoji 官方排错文档有说：https://docs.pingcap.com/tidb/stable/tidb-troubleshooting-map#62-data-migration 另外参考一篇 blog 也有提到：https://izualzhy.cn/interesting-encode，\ufffd这个非常常见，是无法转换的时候就会转成这个编码的。 目前…

这个问题我们之前也遇到了，除了官方文档提到的两个参数（txn-entry-size-limit&raft-entry-max-size)，在我们的实践中，发现还有第三个隐藏参数需要调整： max-grpc-send-msg-len : 用于设定 grpc 最大消息体大小，截止 2021.07.10 ，该参数未被在文档中提及，属于「隐藏配置项」，时在排查问题时才从官方研发团队获知的一个参数

不急的，不是正式环境，就是在做一些数据迁移 补充下背景： dm 迁移的时候没有配置跳过utf8 check， 附图上的全程测试也没有设置这个 utf8 check 跳过 tidb_skip_utf8_check

我把表结构直接贴出来文本吧： *************************** 1. row *************************** Table: game_character Create Table: CREATE TABLE `game_character` ( `_id` bigint(20) unsigned NOT NULL, `uid` bigint(20) unsigned NOT NULL, `gid` bigint(20) unsigned NOT NULL, `gtype` int(10) unsigned NOT N…