目录

系统架构

网络层面

网络丢包，重传

网卡满 比如大字段

网络链路变长

受到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突然变慢。

---