1. 慢查询日志
MySQL的慢查询日志是MySQL提供的一种日志记录，它用来记录在MySQL中响应时间超过阀值的语句，具体指运行时间超过long_query_time值的SQL，则会被记录到慢查询日志中。long_query_time的默认值为10，意思是运行10S以上的语句。默认情况下，Mysql数据库并不启动慢查询日志，需要我们手动来设置这个参数，当然，如果不是调优需要的话，一般不建议启动该参数，因为开启慢查询日志会或多或少带来一定的性能影响。慢查询日志支持将日志记录写入文件，也支持将日志记录写入数据库表。
2. 慢查询造成的影响
慢查询造成的影响包括但不限于以下几点:
增加接口的响应时长.从而间接增加整体服务的平均响应时长,进一步影响整个集群的可用性.
大量慢查询会导致数据库的session长期被占用.造成共同使用的其他服务或者接口连接数据库失败.
增加mysql的CPU和内存的使用率,导致mysql的服务可用性下降.
服务接口的整体耗时增长间接导致服务的整体可用性下降(5xx错误和超时).
带宽长期占用,导致影响到其他服务.
3. 数据库慢查询出现的一般情况
大批量的更新数据
不恰当的汇总数据
去根据一些条件进行数据汇总,如果这样的情况不可避免,那么也应该合理去设计缓存.避免直接去操作数据库.同样是O(N).
大量数据操作
一次性取非常多的数据量,会导致IO问题,比如我们一次从数据库获取1000条数据,每条数据2K,那么这样的请求一个请求就会占用10002k = 2M的 带宽,这样的操作如果有1000QPS ,那么一秒中的带宽占用就是 10002M = 2G,这样的带宽占用对于一个服务器来说是致命的. 解决办法就是合理的设计接口和服务,该分页分页,只取需要的字段.不要动不动就select * .
耗时较长的事务操作
当我们开启一个事务的过程中,会导致数据库给事务涉及的数据上锁,所有其他需求该行数据的请求都会受到影响, 所以耗时较长的事务,应该考虑是否能够用分布式事务的方式来处理.并且一些情况下 我们需要考虑是否能够不使用事务.
联表查询
联合查询在一些情况下也会造成数据库的慢查询,主要是因为在联表查询的过程中,数据库的执行过程往往很难用到索引.可以考虑是否能够通过冗余一些数据来避免联表查询,空间换时间.拆分查询到单独的表上,并使用索引.
非索引查询
在数据库的交互过程中,索引起到了至关重要的作用,合理的建立数据的索引能够很大程度上的避免造成慢查询.而慢查询出现最多的场景,往往就是没有正确建立索引.
我们去更新一个表里面的所有行的某个字段,这种操作不应该出现在接口层面.因为这样的操作对数据库来说时间复杂度为O(N),N为数据行数.
4. 慢查询通常的监控方式
mysql的慢查询日志监控
纳入自定义的监控平台进行监控
