【 TiDB 使用环境】生产环境
【 TiDB 版本】 6.5.9
【复现路径】压测一段时间后间隔出现
20+节点集群，32c128g的云主机，TiDB和TiKV混布，出现了少量SQL请求，parse time和generate plan time时间在1-5秒，远高于正常值，99分位的延迟正常。
1.检查TiDB日志：查看TiDB的详细日志，特别是在出现延迟的SQL请求时，日志中包含有关查询性能问题的线索。
2.分析慢查询：使用TiDB的慢查询日志功能来识别那些导致延迟的SQL语句。检查这些查询是否存在性能瓶颈，如复杂的查询逻辑、大量的数据处理等。
3.查询执行计划：对于出现延迟的SQL语句，查看其执行计划。有时候，即使解析时间和生成计划时间正常，执行计划本身可能会导致性能问题。检查是否存在全表扫描、连接过多、子查询等问题。
4.监控TiDB和TiKV的负载：虽然CPU和内存使用没有达到上限，但这并不意味着没有负载。检查是否存在I/O瓶颈，或者TiKV的存储层是否存在问题。
IO不大正常范围，延迟的SQL语句执行计划也正常，慢查询日志里耗时分析全花在parse time和generate plan time上面。
是什么样的SQL
主要是批量更新和点查，但是感觉和SQL具体关系也不大，因为看耗时执行计划生成后执行很快，就卡在parse和generate plan，而且同一时间段高延迟的SQL都出现在同一台Tidb-server上，和具体的sql类型无关。
profiling 发现gcbgmarkworker，gc相关的占了tidb-server 30%的cpu
高并发，tidb tikv 混布。 我认为cpu变高属于正常，并发数据，sql数据，需要对比下才能说出结论吧。sql解析和生成计划 以及 gc处理 如果存在抢机器资源的情况，数据变高，个人认为也正常。高的异常也得有数据分析。
但看监控tidb + tikv的cpu连机器一半都没到，但是sql解析和执行计划生成就开始会有很大的延迟了，给我的感觉是cpu资源没有被利用到。
云上就不要混合部署了