【 TiDB 使用环境】 测试
【 TiDB 版本】v7.5.3
【复现路径】v7.5.2版本在高并发【30个并发】请求后tiflash性能陡降，tiflash的cpu能占到90c左右的，但是看v7.5.3版本已修复这个问题，不知道社区的同学是否测试过呢，bug连接：Lock contention is severe when query concurrency is high · Issue #9125 · pingcap/tiflash · GitHub
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
我自己的使用体验是，要看下tiflash在执行计划中是做扫描还是做聚合。
做聚合，我觉得并发高点也就高点，如果是扫描，那没几个并发可能就趴下了。
如果tiflash确实在做它擅长的事，资源不够就是资源不够。
如果tiflash干了它不该干的事，给多少资源恐怕也填不满的。
只是一些行检索比较多的sql请求，sql本身不复杂【无join , union, group by 等】，所以说tiflash产品的定位是什么呢？
可以说是扫描，没有聚合
这就是典型的扫描操作，不该tiflash做。
tiflash擅长的，就是带group by的。带group by的情况下join/union也复杂一些也无所谓。
但不带group by的情况下纯扫描行数据，性能不如tikv非常正常。
通过测试发现，确实如此，看来是选型有问题
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。
