慢查询有开启
根因：应用端连接参数不兼容 TiDB 8.5.6，导致结果集拉取阻塞、流水线等待；
差异点：数据库端直连无客户端瓶颈，所以极快；
修复：调整 JDBC 连接参数 + 刷新计划缓存 + 重启连接池即可秒级恢复。
哪个参数？
“TiDBConnectionString”: “server=12.18.1.3;port=4000;database=dbname;uid=username;pwd=password;Connect Timeout=500;Old Guids=true;pooling=true;SslMode=None;Allow User Variables=True”
数据库的连接字符串是这样的，是那个参数不兼容啊？
客户端仅统计子查询总行数；应用侧需处理大批量数据，SQL 拼接、统计、数据传输开销更高。
可以试试 JDBC 连接串配置fetchSize=1000，或调整 tidb_opt_fetch_batch_size 参数。
调整 stream 参数、JDBC 关闭游标全量读取、更新统计信息。
是 v8.5.6 本地流式执行逻辑变更引发的分批拉取等待堆积，调小tidb_min_local_stream或关闭本地流可恢复性能。 执行set tidb_enable_local_stream = off;临时回退兼容旧版读取逻辑即可消除耗时。
库内100ms、应用端10-300s，且执行计划里 pipeline_queue_wait、fetch and wait 明显偏大，说明慢在结果返回和算子间的流水线等待，不是计算本身。这类升级后变慢常见于两点：一是 8.5.6 对某些算子并行度或 chunk 拉取策略有调整，min/max_local_stream 变大意味着数据在 stream 间等待；二是应用端一次性拉取大结果集，网络往返和 fetch 批次放大了等待。排查建议：对比升级前后该 SQL 的完整执行计划和 tidb_distsql_scan_concurrency、tidb_max_chunk_size 等会话变量；确认应用端是否用了流式游标逐批取数导致 RTT 累积。若是 count 外套子查询，可尝试改写为直接聚合减少中间结果传输。