m0_74299224的博客

不过实际分析的时候，我们会去看当时是对象哪个占的大，随后有historym去看调用的线程，查看哪个线程发生了问题，追踪线程的操作，当时在干什么，找到问题线程之后，拿当时的相关信息，进行翻译转义，最后结合业务特点进行代码的修改即可。MQ是不是本身就有三次重试？这个时候有同学就会问了，主播主播，你的降级确实很有东西，但是跨系统非自产自销的怎么办呢，你不能强制对方给你弄个接口吧？首先是共有的，既然不能完全信任MQ，那么我们代码块中一定要有try catch（当然了，主流的MQ客户端一定会有异常抛出的）

本文介绍了在解决数据库查询性能问题时的一般步骤。首先，需要定位问题，查看监控工具的线上流量和服务器健康情况，以及实际调用量。然后，可以使用MongoDB的Explain工具进行慢查询分析，类似于MySQL的Explain。通过分析索引走向、执行计划等信息，可以找到潜在的问题，并考虑重建索引或创建联合索引来优化性能。在解决问题时，需要评估风险并考虑业务特点，确保解决方案有效且不会对现有服务造成不必要的影响。

原先的流程是 先看服务的调用、再看机器的CPU情况、随后看DB的压力均衡情况、如果上述都平稳看clickHouse链路的Trace情况，定位位置、如果是SQL的问题去看慢日志、分析索引、分析语句。（2）SQL的查询优化——从SQL语句本身出发（链表查/JOIN的时候考虑JOIN的索引）（4）业务代码是否某环节调用时间过长，是内存计算有问题还是什么原因（例子）（2）能否进行数据缓存（本地缓存或者Redis的中间件数据缓存）（3）锁竞争情况分析（当然对于select来说相对会少一点）（1）能否用异步调用优化。