SQL 在 TiDB 执行耗时正常，但客户端 fetch 数据极慢，且表现为 fetch and wait 等待高，应该优先检查哪些配置？
- 优先检查配置
- 驱动 / 客户端 fetch_size / batch_size（批量拉取行数）
- 服务端 tidb_distsql_scan_concurrency（并发读取）
- 服务端 tidb_projection_concurrency（结果集投影并发）
- 网络参数 tcp 窗口、net.ipv4.tcp_syncookies 等
- TiDB result-cache / result-buffer 相关输出缓冲区
- 根因方向：批量拉取过小、网络吞吐不足、服务端结果集输出并发不足。
Fetch And Wait 绝大多数由游标分批拉取（cursor fetch）+ fetchSize 过小导致：客户端每消费完一批才发请求取下一批，TiDB 空闲等待客户端 ACK，出现长时间fetch and wait。
- useCursorFetch
useCursorFetch=true：开启服务端游标分批取，fetchSize=10/100 极慢；批量导出 / 全量查询建议关闭：useCursorFetch=false（一次性缓存结果到 JDBC 内存，无分批等待）- 流式拉取：
fetchSize=Integer.MIN_VALUE(-2147483648)，MySQL 流式协议，边算边推数据，无客户端阻塞
- fetchSize
- 批量查询推荐：
fetchSize=1000~5000；禁用fetchSize=1/10小批量
- 连接串优化：
useConfigs=maxPerformance，屏蔽 JDBC 频繁元数据查询损耗TiDB
优先改 JDBC，改完立刻观察 Fetch And Wait 指标回落。
从数据库设计角度，这类问题通常可以归结为数据模型和访问模式的匹配度问题。具体需要看你的 schema 和查询模式才能给出更针对性的建议。
优先检查客户端fetch_size批量拉取行数是否过小，以及网络吞吐和TiDB服务端的tidb_distsql_scan_concurrency并发设置。
从数据库设计角度，这类问题通常可以归结为数据模型和访问模式的匹配度问题。具体需要看你的 schema 和查询模式才能给出更针对性的建议。
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。