携手奔赴下一个十年！

max-snapshot-count可以设置大一点再看下

down的store已经没有leader了，可以直接用tiup缩容掉，重新扩一下这个节点。

analyze是系统sql，一般不会影响整个集群性能，无需过于关注，除了analyze之外有没有其他业务sql慢的

我这边实际测了一下，对于right这个expression index，dm的parser应该还没有支持。提了个issue，等修复吧。 https://github.com/pingcap/tiflow/issues/12461

binlog_row_image这个值改过吗，可以用mysqlbinlog命令解析下卡住的binlog位置看下内容

可以发下tidb的启动日志看看，allow-expression-index参数是否已经生效，修改tidb参数需要reload一下

应该是raft message的cache满了

dumpling导出指定一下–loglevel debug看看有没有别的信息

是的，先扩容好pump，再开启binlog

可以试试这种方式：https://docs.pingcap.com/zh/tidb/v7.1/use-tispark-to-read-tiflash/#使用-tispark-读取-tiflash

默认系统内存的45%

看执行计划，这两个表的数据量差距较大。 link1表11040521行 link表194142行

1、检查所有tidb的binlog写入状态： curl http://tidb_ip:10080/binlog/recover?op=status 2、如果有skip的手动恢复一下 curl http://tidb_ip:10080/binlog/recover

可以删除，可以考虑添加log的相关配置自动删除 https://docs.pingcap.com/zh/tidb/v7.5/tidb-configuration-file/#logfile

刚看了下版本，是只记录server的执行时间了。

这个sql里有视图吧，用户没有对该视图show view的权限。

这个需要结合具体的执行计划看一下，发一下两个sql的执行计划吧. https://docs.pingcap.com/zh/tidb/v6.5/sql-statement-explain-analyze/#explain-analyze

这个可能不是慢在tidb，怀疑客户端响应慢。可以考虑在select 1慢的时间点在数据库里执行看看时间