系统慢查询的思考

在一个系统中发现慢查询的功能或很卡的现象。你是怎么思考的？从哪几个方面去思考？会用什么工具？

一个系统使用了几年后都可能会出现这样的问题。原因可能有以下几点。

1. 数据量的增加。系统中平时的使用中数据量是有一个累计的过程的。单表的数据量达到一定数量后就会出现原来执行性能还不错的SQL变慢了。
2. 用户量的增加。 公司业务的不断扩展，系统的用户量也会跟着增长。用户量增长了，系统的访问量也会同步增加的。这时系统的压力就会增加。原先的服务器可能就无法承担现有的压力了。现在去服务器的使用很多，使用去服务的用户还要考虑流量带宽是否够不够用了。
3. 系统功能设计不合理。业务功能太复杂而没有进行接口性能考虑。
4. 系统耦合高。对外依赖高受外部接口性能影响。
5. 代码质量差。未考虑接口性能。Sql未合理设计索引。
6. 系统架构不合理。

  

我们先从整合上来想一想有哪里节点可能会影响系统性能问题？

一个请求从用户端发出要经过很多节，简单的说会先到应用服务器进行业务逻辑处理，在进行业务处理时会用到数据库数据。

小型系统如果没有较大的用户量的增加时更多的是考虑单表数据量的增加导致的查询慢。

1. 数据库慢SQL监控分析日志：用于找到查询慢的SQL，分析是否要进行优化或加索引。
2. 接口性能日志：记录接口的处理用时，请求时间。分析接口高峰时间段，处理时长等。找到影响最大的接口，再进行代码分析，最后结合慢SQL日志一起分析，找到慢的原因，再确定解决方案。
3. 前端请求接口日志：这里可以更直观的看到用户等待的时间。一个用户请求要经过公网－>DNS服务器－>负载均衡服务器－>应用服务器－>数据库。要经过这么多个节点。服务端只能监控到接口处理用时。而无法监控每个节点的等待时间，如大量用户请求在到达了应用服务器后在对列中等待了多久这是接口性能日志无法记录到的。
4. 用户操作日志。这个日志不是很重要，如果有也可以进行一些用户操作行为分析。提高

有了这些数据就不难发现问题点了。

1. 接口性能数据差。那就找到要优化的接口进行代码。这时可以先考虑优化代码和SQL。再进行业务解耦，如果有对外部接口依赖的可进行解耦异步设计，如果数据库读操作多，可以增加缓存服务器，减少数据库压力，提高接口性能。
2. 接口性能数据都很好的情况下，但前端请求接口日志性能差。说明可能是应用服务器的等待对列太长了。说明访问量较大，原有的服务器处理不过来了，且接口性能已没有性能提升的可能时，才是进行增加服务器增加负载均衡的设计。如果服务器的性能不错的话，也可以增加IIS站点的方式解决等待对列长的问题。

对于超大访问量的应用来说。就要用到更高级的架构了。数据库的读写分离，数据库集群，应用服务器集群，缓存集群，消息对列等。根据应用的发展增加相应的组件。