【 TiDB 使用环境】生产环境
【 TiDB 版本】5.3
【复现路径】不能复现，每天不定时出现，几分钟后自动恢复
【遇到的问题：问题现象及影响】出现大量慢查询
【资源配置】
【附件：截图/日志/监控】
看看 Dashbord，慢的时候CPU和IO情部是怎么样的,当时有无慢SQL在执行
遇到过这种情况，偶尔几秒钟慢的，后来发现是CPU和IO被服务器的其他定时任务给占了，导致SQL查询慢
看下对应时间点的 top sql 是不是有什么大sql
看下出现时间段的CPU和内存是否负载比较高，再分析下这个时间段执行的SQL执行计划
- 资源限制：在 OLAP 或 OLTP 业务中，资源限制可能导致慢查询。例如，如果数据聚合接口平台有大量接口实时查询数仓 ODS 层，而这些接口的响应时长受数据库查询速度的显著影响1。
- 统计信息失效：TiDB 使用统计信息来优化查询，如果统计信息过时或不准确，可能导致优化器生成低效的查询计划。例如，参数
pseudo-estimate-ratio用于判断统计信息是否失效，如果表更新频繁且未及时使用ANALYZE TABLE更新统计信息，可以考虑调整该参数或使用tidb_enable_pseudo_for_outdated_stats参数2。 - 查询计划问题：查询计划的优劣直接影响查询性能。通过
EXPLAIN语句分析查询计划，找出可能的性能瓶颈，如全表扫描、索引使用不当等。 - 热点问题：数据热点可能导致某些 Region 负载过高，从而引发慢查询。使用 TiDB Dashboard 监控数据热点并进行相应的优化3。
- 慢查询日志分析：通过分析慢查询日志，可以找出执行时间长的查询语句，并针对性地进行优化。TiDB 提供了
information_schema.slow_query表以及admin show slow命令来检索慢查询4。 - 系统监控和诊断工具：利用 TiDB 提供的系统监控诊断工具，如 TiDB Dashboard 的 Statements 功能，可以监控和诊断运行中的查询，帮助定位性能问题5。
- 慢查询日志参数调整：根据需要调整慢查询日志的相关参数，如
tidb_enable_slow_log、tidb_slow_log_threshold等，以便更有效地记录和分析慢查询6。
找下慢查询的sql有没有什么规律，是不是每次都是某几个sql造成的，不定时出现，感觉像是人为的
定位语句先
有一个tikv节点，cpu很高，导致的慢查，但平时这些慢查sql执行很快，平均10ms内。业务qps也没有明显异常波动，热力图上可以找到cpu高的时间点，有一张表读取流量很大，每分钟200G+，怀疑是某些sql执行计划走偏。
多数由于analyze table造成的
这个clinic我看不了，找谁开下权限？
不知道如何开权限。
慢查中查到分析表和cpu高的时间点对应不上，compaction的时间点也对应不上。
从应用上入手排查
使用TiDB Dashboard或第三方监控工具查看慢查询日志。
分析慢查询日志，查看是哪些查询变慢，以及它们的执行计划。
检查系统资源使用情况，确定是否存在资源瓶颈。
先看看语句
看topsql 修改里面耗时的sql
定位语句
TiDB的dashboard上可以查看慢sql及sql语句分析，分析这些慢sql。
看看对应时段的SQL执行了啥
你这现象很明显， 直接 dashboard 里面的 top sql ，然后选下对应的节点，就能找到有问题的sql了