业务系统反应卡顿数据库mysql5.7.33

前言：

系统卡顿已经有好长一段时间，在排除了操作系统和数据库等相关方面的问题，首先发现的是数据库服务器资源使用率较高，CPU经常在90%左右，开始以为是是资源不足问题，尝试对服务器扩容CPU，从16扩容到32，发现CPU使用率仍然是很高，业务系统同样出现卡顿的情况，平均每天出现十几次。另外一个问题就是发现用户卡顿的业务表的存储引擎是MySIAM，看到这个就觉得奇怪，主要的业务表怎么会使用这个存储引擎呢？不解。后经过系统管理员与系统开发商的了解才知道，当初开发商是为了全文索引才把表设计为MySIAM，但是经过一番查询之后，mysql在5.7.33版本Innodb存储引擎是支持全文索引的（现在这个库的版本是5.7.33的，我查了一下5.7.6之后版本貌似innodb也支持全文索引了）。

一、xx系统卡顿优化案例
故障现象：
失物招领系统基本每天都收到用户使用卡顿的报障，持续十几分钟的卡顿或者更长时间。

现象分析：
(1)系统层面：
初步排查数据库服务器资源使用率较高（内存16GB，CPU16）

(2)数据库层面：数据库版本MySQL 5.7.33，数据库参数配置是默认的，尝试对数据库的buffer pool size进行调整，并开启了慢日志，经过调整之后未发现明显的变化，用户仍时常反馈系统卡顿
优化内存参数：

# innodb缓冲池大小
innodb_buffer_pool_size=8G
# innodb缓冲池块大小
innodb_buffer_pool_chunk_size=128M
# innodb缓冲池实例数
innodb_buffer_pool_instances=8
在线调整：
SET GLOBAL innodb_buffer_pool_size = 8589934592

在 /etc/my.cnf 添加如下参数

slow_query_log=ON
long_query_time=2

在线开启慢日志：

set global slow_query_log=1;
set global long_query_time=2;
show variables like 'slow_query_log';
show variables like 'long_query_time';

(3)分析数据库大小情况以及数据库表引擎信息

(4)分析用户反馈系统卡顿的时候相关的会话信息以及SQL语句

综合处理：
(1)首先是对服务器的CPU进行了扩容，扩容后仍未解决系统卡顿的情况
(2)修改表的存储引擎，把MySIAM引擎修改为Innodb引擎。
修改完存储引擎之后，到目前为止暂未收到用户反馈系统卡顿的情况。

ALTER TABLE lcord ENGINE=MyISAM;
ALTER TABLE loscord_temp ENGINE=MyISAM;
ALTER TABLE lostord_temp_ok ENGINE=MyISAM;
ALTER TABLE at_faq ENGINE=MyISAM;

异常处理：
在修改存储引擎过程中，按照预定的处理方案中，lost_item_record转换存储引擎的过程中耗时比较长，持续半个多小时都没有变化，且需要先执行“set sql_mode=‘NO_ZERO_DATE,NO_ZERO_IN_DATE’;”。尝试使用其他方法进行处理，先把lost_item_record表数据mysqldump备份出来。

mysqldump -uroot -p -S /var/lib/mysql/mysql.sock lost ab> /tmp/ab.sql

修改sql文件内容，创建lost_item_record_new表

sed -i s#ab#ab_new#g ab.sql
sed -i s#MyISAM#InnoDB#g lost_item_record.sql

在导入的过程中，速度非常的慢，后经过insert into select * from的方法插入数据，大概耗时30分钟，最后处理完成。