目录

系统架构

网络层面

网络丢包，重传

网卡满 比如大字段

网络链路变长

受到IO影响

CPU/MEM

服务

资源抢占

FullGc

数据库

没有走索引

并行更新同一条数据

数据分布不均

查询不合适

表设计有问题

innodb 刷脏页

系统架构

1. 网络
2. 对中间件的竞争
3. 后端服务本身慢
4. 竞争DB本身
5. DB查询慢

网络层面

网络丢包，重传

如果涉及双数据中心，或者多中心办公场景，就会有这种情况。

可以长时间ping测试丢包情况。

网卡满 比如大字段

使用dstat命令测试网络拥堵情况

网络链路变长

涉及系统集成，涉及老系统，如果调用链路长会导致此类问题。

如果有cat这类分布式链路追踪系统，可以看，否则不怎么好搞

受到IO影响

如果数据库服务 可能有备份服务导致的磁盘IO，CPU，内存被大量占用，导致查询变慢。本质是其他服务占用了“主服务”资源导致。

后端服务如果大批量写文件会导致磁盘IO抢占，导致操作慢

核查：

1. 使用top检查CPU，内存占用的进程
2. 如果是后端服务，查询线程占用内存情况，top -Hp PID
3. 用linux dstat验证IO读写情况

CPU/MEM

CPU和内存 一般都是其他服务被占用导致

服务

资源抢占

比如redis锁，DB连接 等。这类如果并发高就会导致大量线程处于等待状况。

检查：

1. jstack 输出java栈
2. jmap dump快照，使用jvisualvm，jprofiler，mat等工具分析

FullGc

频繁FullGC会造成服务卡顿，CPU占有率升高

检查：

1. 用jstat -gcutil pid 查看gc数量和时间
2. 使用dump文件分析 可能的内存泄露

数据库

没有走索引

随着数据库变多，如果正好某个查询条件没有走索引，查询会比较慢。

检查：

1. 查看慢sql
2. 查看执行计划explain

并行更新同一条数据

常见的秒杀场景:数据库并发执行update，更新同一行的动作会被其他已经持有锁的会话堵住，并且需要要进行判断会不会由于自己的加入导致死锁

数据分布不均

a=11,10条数据

a=21,10W数据，查询自然不同

查询不合适

select *** from tt limit 10000000,10;

这类需要先找到10000000条，然后往后找10条

调整为：

select * from tt where id >= 10 limit 10;

表设计有问题

varchar(2000) text

调整：

1. 纵向拆分，将varchar 2000 这种字段拆分到另一个表

innodb 刷脏页

InnoDB引擎采用Write Ahead Log(WAL)策略，即事务提交时，先写日志(redo log)，再写磁盘。为了提高IO效率,在写日志的时候会先写buffer，然后集中flush buffer pool 到磁盘。 这个过程 我们称之为刷脏页。

这个过程中就有可能导致平时执行很快的SQL突然变慢。