【 TiDB 使用环境】生产环境
【 TiDB 版本】7.5.4
cop执行时间不到1分钟，但是发送结果的耗时达到了10分钟
tidb-server的网卡流量并不高
客户端的监控也看下，可能不止tidb问题
1 个赞
你这都浪费在发送客户端了，网络延迟看了吗
1 个赞
如果流量不高，又发送时间很长，是不是带宽问题？我们遇到过一次是3个节点，有一个节点是百兆带宽，然后就特别慢。
2 个赞
我觉得两方面
1 检查数据库服务器的网络带宽使用情况。如果带宽接近饱和，会导致数据发送缓慢
2 查看数据库的缓冲区配置参数，如MySQL的 innodb_buffer_pool_size
1 个赞
tikv到tidb之间的网络，还有tidb到客户端之间的网络，都排查下
1 个赞
如果网络没问题，看看你的数据啥样，是不是有很长的字段
1 个赞
有两点供你参考：
- 查询返回的结果大概多少行记录？
- client → server 请求后，需要server(tidb) 返回给 Client，数据量较大的情况下，client性能不好，资源不足只能慢慢处理？需要排查client 端的日志
- client → server 网络带宽 是否有瓶颈？
- client 是否能支持流式处理？解决性能瓶颈的问题. （JDBC 的协议是支持的）
1 个赞
客户端内存cpu和带宽看看
1 个赞
试试通过调整TiDB或TiKV（TiDB的存储层）的相关配置参数，是不是可以改善性能。例如，调整coprocessor相关的配置项来优化执行计划
1 个赞
几个方面，客户端及应用程序，网络，TiDB：
1，结果集大小？
2，客户端本机当时在干嘛，CPU，网络，内存等资源是否够用？网络自己用的少，也许别的用了？
3，应用程序是怎么处理逻辑的？如果一边取一边同步处理，那就比较慢。这是符合预期的？不符合是否需要修改应用逻辑？
上述123可以通过等价sql拷贝到mysql 命令行或者dbeaver等客户端测试一下，排除是否客户端的问题。
4，如果是数据库侧tidb发的慢，可以看下tidb的资源，光看网络不够。另外也许是并发参数有人做了修改（参考：tidb流式读取配置_tidb 流读-CSDN博客 ）。
1 个赞
看了各个组件的最大带宽，最小都是2Gbit/s
那有可能就是带宽问题吧
结果集多大呢，这个发送结果的时间包括客户端收到并返回ack的时间，所以还需要考虑客户端的资源及性能问题的
1 个赞
感谢回复，看了客户端的资源使用率，在当时已经使用了100%，应该是这个原因导致