数据库层面
一：检查问题常用工具
1：msyqladmin：MySQL客户端，可进行管理操作
2：mysqlshow：功能强大的查看shell命令
3：show [SESSION | GLOBAL] variables：查看数据库参数信息
4：SHOW [SESSION | GLOBAL] STATUS：查看数据库的状态信息
5：information_schema：获取元数据的方法
6：SHOW ENGINE INNODB STATUS：Innodb引擎的所有状态
7：SHOW PROCESSLIST：查看当前所有连接session状态
8：explain：获取查询语句的执行计划
9：show index：查看表的索引信息
10：slow-log：记录慢查询语句
11：mysqldumpslow：分析slowlog文件的
二：解决思路
一般应急调优的思路：针对突然的业务办理卡顿，无法进行正常的业务处理，需要立马解决的场景
1：show processlist；
2：explain select id ,name from stu where name='clsn'; # ALL id name age sex；
select id,name from stu where id=2-1 函数 结果集>30；show index from table；
3：通过执行计划判断，索引问题（有没有、合不合理）或者语句本身问题；
4：show status like '%lock%'; # 查询锁状态
kill SESSION_ID; # 杀掉有问题的session。
常规调优思路：针对业务周期性的卡顿，例如在每天10-11点业务特别慢，但是还能够使用，过了这段时间就好了。
1：查看slowlog，分析slowlog，分析出查询慢的语句；
2：按照一定优先级，一个一个排查所有慢语句；
3：分析top SQL，进行explain调试，查看语句执行时间；
4：调整索引或语句本身。
系统层面
一：检查问题常用工具
Cpu方面：vmstat、sar top、htop、nmon、mpstat；
内存：free、ps-aux；
IO设备（磁盘、网络）：iostat、ss、netstat、iptraf、iftop、lsof；
vmstat命令说明：
1）Procs：r显示有多少进程正在等待CPU时间。b显示处于不可中断的休眠的进程数量。在等待I/O。
2）Memory：swpd显示被交换到磁盘的数据块的数量。未被使用的数据块，用户缓冲数据块，用于操作系统的数据块的数量。
3）Swap：操作系统每秒从磁盘上交换到内存和从内存交换到磁盘的数据块的数量。s1和s0最好是0。
4）Io：每秒从设备中读入b1的写入到设备b0的数据块的数量。反映了磁盘I/O。
5）System：显示了每秒发生中断的数量（in）和上下文交换（cs）的数量。
6）Cpu：显示用于运行用户代码，系统代码，空闲，等待I/O的Cpu时间。
iostat命令说明：
实例命令：iostat -dk 1 5
iostat -d -k -x 5 （查看设备使用率（%util）和响应时间（await））
1）tps：该设备每秒的传输次数。“一次传输”意思是“一次I/O请求”。多个逻辑请求可能会被合并为“一次I/O请求”。
2）iops ：硬件出厂的时候，厂家定义的一个每秒最大的IO次数
3）"一次传输"请求的大小是未知的。
4）kB_read/s：每秒从设备（drive expressed）读取的数据量；
5）KB_wrtn/s：每秒向设备（drive expressed）写入的数据量；
6）kB_read：读取的总数据量；
7）kB_wrtn：写入的总数量数据量；这些单位都为Kilobytes。
二：系统层面问题解决办法
你认为到底负载高好，还是低好呢？在实际的生产中，一般认为Cpu只要不超过90%都没什么问题。
当然不排除下面这些特殊情况：
Cpu负载高，IO负载低
1）内存不够；
2）磁盘性能差；
3）SQL问题--->去数据库层，进一步排查SQL 问题；
4）IO出问题了（磁盘到临界了、raid设计不好、raid降级、锁、在单位时间内tps过高）；
5）tps过高：大量的小数据IO、大量的全表扫描。
IO负载高，Cpu负载低
1）大量小的IO写操作：
autocommit，产生大量小IO；IO/PS，磁盘的一个定值，硬件出厂的时候，厂家定义的一个每秒最大的IO次数。
2）大量大的IO 写操作：SQL问题的几率比较大
IO和cpu负载都很高
硬件不够了或SQL存在问题。
来源：CSDN
作者：Java技术践行者
链接：https://blog.csdn.net/eafun_888/article/details/104738612