【 TiDB 使用环境】生产环境
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
同一个SQL 跑tiflash，rpc_time 有时长 有时短，如何优化，排查
正常的时候 十几秒跑完，不正常的时候就几分钟起步
参考下~
有时候 突然大量的sql 执行慢 看着特别简单的sql都慢， 13:50 当时 tidb tikv tiflash 看 各个组件的CPU没有明细异常升高 。
感觉这个不需要走tiflash,创建合适的索引应该合适
sql命令一直都很快 ， 就是偶尔有时会卡 。 重点不在于走不走tiflash 。
正常不正常，执行计划都是一样的吗？
一样的，走的都是tiflash
怎么样判断你这个 SQL 要走 tiflash 而不是索引 tikv
看下tikv-details下面grpc监控在你这个sql慢的时间点有问题吗。。。
变慢的SQL是简单的单表查询么？如果是简单查询在高峰期变慢，可以考虑一下
tidb_allow_batch_cop这个参数调整为2(不过我也没实际测试过，需要你来验证了。。)
如果是统一都变的很慢，可以看下
tidb_max_tiflash_threads这个参数，看值是什么。
我猜可能是在某个阶段排队导致的
可以排查那一段时间的慢SQL执行记录,然后再分析一下，可能是那一个时间节点上数据库内存、CPU负载很高
grpc message duration波动的峰值和sql慢的时间一致吗？
有个定时任务会频繁建表导数据，可能是他导致的。
tiflash 会同步 没有 副本的schema。这块可能是原因。这个table 会定期删除重建，但是不会放到tiflash，结果就是tiflash频繁报这个异常
之前没有这种情况 ， 应该是升级6.1.2之后的 ，看看相关技术能不能根据这个告警日志 排查一下什么问题 ， 为什么定期重建表 会导致tiflash 不稳定。
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。