【TiDB 使用环境】生产环境
【TiDB 版本】v7.5.0
【部署方式】物理机部署
【操作系统/CPU架构/芯片详情】CentOS 7.9 / x86_64
【机器部署详情】TiDB节点：16核64GB / TiKV节点：32核128GB，NVMe SSD 3TB / TiFlash节点：32核128GB，NVMe SSD 2TB / PD节点：8核16GB
【集群数据量】约 8TB（TiKV）+ 2TB（TiFlash）
【集群节点数】2 TiDB + 3 PD + 3 TiKV + 2 TiFlash
【问题复现路径】业务将部分OLAP查询路由到TiFlash，日常运行稳定，但每天下午14:00-16:00之间会出现间歇性的读延迟毛刺，某条聚合查询从平均80ms暴涨到3-5秒，持续几分钟后自动恢复
【遇到的问题：问题现象及影响】BI报表生成任务在该时段频繁超时失败，影响到运营侧的数据看板展示，业务方多次投诉
【资源配置】[此处插入Dashboard主机截图
但每天下午14:00-16:00之间会出现间歇性的读延迟毛刺，某条聚合查询从平均80ms暴涨到3-5秒，持续几分钟后自动恢复
有拿到这部分异常或者毛刺的日志，或者运行状况的分析么？
定时段毛刺优先对照该窗口的资源争用：TiFlash CPU/IO、MPP 任务排队、是否与备份/统计信息收集/大批量导入重叠。用 Dashboard 慢查询与 TiFlash 监控看毛刺时是否 Exchange/Scan 变慢。处理：错峰重查询、给 TiFlash 独立资源、核对副本同步延迟；确认路由是否偶发回退到 TiKV 行存扫描。
业务高峰期系统资源出现瓶颈，导致TiFlash节点产生间歇性的长尾延迟。
学习了
看日志像是遭遇突发的资源瓶颈。
从描述看，这个时段性的读延迟毛刺大概率是资源争抢或热点问题，建议按以下顺序排查：
-
检查TiFlash和TiKV的CPU/IO监控：14:00-16:00是否有其他批处理任务（如备份、analyze、数据导入）在跑？用
top或Grafana看下TiFlash节点CPU是否打满，IO延迟是否升高。 -
看TiDB Dashboard的Top SQL：确认毛刺期间是哪条SQL，执行计划是否走了TiFlash，有没有发生MPP任务重试或落盘。
资源瓶颈方面：可以关注下coprocessor cpu、网卡是否存在打满的现象？
解决方面：还是要找到资源消耗高的SQL然后想办法优化。另外可以和开发团队沟通下，数据看板里的所有数据是否都要走数据库跑AP？秒级延迟就无法接受的数据，能否改为读取redis？
① TiFlash 后台 DeltaMerge/GC 任务抢占资源（最高概率）
② PD 调度（Region 迁移、Snapshot 同步 TiFlash）定时触发
③ 业务窗口写入量上涨 → TiFlash 同步延迟 + 版本堆积
④ SQL 优化器动态选择、MPP 并发争抢、TiDB 负载均衡波动