一般来说,先看监控,看日志,看慢查询,看资源使用情况,并发情况,然后对症下药
altermanager告警–>TOP sql/Grafana查看异常–>慢查询 优化
一般都是dashboard+grafana+日志，针对不同的故障查询不同的页面。
再就是来论坛找类似的经验
深有感触
【排查问题】从操作系统到中间件到应用到数据库，一步步定位，当然有一定经验后，一看就大概能猜到是哪儿的问题，然后深一步查
【解决问题】找到问题点之后，就是怎么解决了，这需要具体问题具体分析
【记录及完善】需要一下预防措施，防止再次出现，或出现后能更快都解决
问题现象；监控；db日志@OS日志。
监控多而杂，希望TiDB融入AI后的错误定位及对应的解决方案自动弹出。
dashboard界面加上日志
日志+面板+现场
监控和日志
遇到过某台TIDB SERVER停止响应的情况，最快恢复方法： 重启了服务器后，重新启动TIDB SERVER
就是看看
一般我们又较全方位的全局监控，一般情况就能分别出是否事 TiDB 数据库自身的故障，如果需要进一步的话，就分析 Dashboard 和 TiDB 的 Grafana 监控大盘。
使用的云环境比较多
大部分时间是在优化慢SQL
第一步肯定是看监控
第二步查看实时SQL，看事务时间较久的是否需要查杀，是否需要手动限流
第三步查看是否有锁，有些锁等待会隐藏，在PROCESS LIST里看不到的，如果有等待查看等待原因，产生锁等待的表及执行实际的SQL
优化慢SQL，首先加缺失索引，适当增加；其次看是否需要修改SQL写法，这个就灵活了，半链接、子查询、增加Hints等等；最后再看表结构是否需要调整，字段冗余，表适当合并、拆分。
数据库负载高先监控看那个节点高,然后去那个节点看具体的sql,优化慢sql
dashboard+grafana+日志+sql脚本大全
dashboard+慢查询