查询慢查询数量
慢查询的数量保存在mysql库里面的slow_log表。
SELECT * FROM slow_log where start_time > ‘2022/09/08 00:00:00’;
查看当前进行的查询状态
show processlist 查看当前系统中正在执行的查询
查看当前所有的process
select * from information_schema.processlist
查看当前正在进行的查询并按照已经执行时间倒排
select * from information_schema.processlist where info is not null order by time desc
正常运行的数据库，因为一条查询的执行速度很快，被我们的select抓到的info不是null的查询数量会很少。我们这样负荷很大的库一般也就只能查到几条。如果一次能查到info非空的查询有几十条，那么也可以认为系统出问题了。
系统问题和定位
当我们察觉到系统变慢之后，马上用慢查询和查看processlist的方式做了检查，结果发现每分钟慢查询数量飙升到1000多，同时淤积了大量的查询在执行中。
因为当务之急是尽快恢复系统的正常运行，因此影响最直接的做法是在processlist的查询结果中，查看有多少哪些查询处于lock状态，或者已经执行了很长时间，把这些process用kill指令干掉。
1查询是否锁表
show OPEN TABLES where In_use > 0;
2查看正在锁的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
3查看等待锁的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
4查看innodb引擎的运行时信息
show engine innodb status\G;
5查看造成死锁的sql语句，分析索引情况，然后优化sql语句
MariaDB [(none)]>kill566698;
1查看服务器状态
show status like ‘%lock%’;
2查看超时时间：
show variables like ‘%timeout%’;
慢查询表查询结果里面有几个比较重要的指标：
start_time 开始时间，要通过这个参数，配合系统出问题的时间，定位哪些查询是罪魁祸首。
query_time 查询时间
rows_sent 和 rows_examined发送的结果数以及查询扫过的行数，这两个值特别重要，特别是 rows_examined。基本上就能告诉我们，哪个查询是需要注意的“大”查询。
实际操作中，我们也是把有大量rows_examined的查询一个个拿出来分析，添加索引，修改查询语句的编写，来彻底的解决问题。