前几天一位前辈说他公司24核的cpu,但是 mysql cpu 占用居然是100%,这个牛逼了,毕竟24核啊,不过是不停地查询插入,于是今天腾出空来查看了下沙沙野的cpu占用,结果也是100%… 出于极客精神,我决定修复它,最后也的确解决了,于是有了此文。
1、top 这个Linux命令很简单,你可以理解为Windows的任务管理器吧。
2、show full processlist; 这是MySQL的命令用于列出当前正在运行的sql语句,以分析性能。
通过 show full processlist; 你应该能看到这么几个指标:Id、User、Host、db、Command、Time、State、Info、Progress 其中db、Time、Info非常有用,前者是数据库,接着是耗时,单位秒,最后是sql语句。如果发现time比较大,那明显这条语句耗时严重,可考虑优化。而db则告诉你这条命令是运行在那个数据库的,对于我,这里的Info如下:
select pic.content, pic.width, pic.height, pic.type, pic.videoCover, pic.userId, pic.seo_alt, pic.createdAt, pic.link, pic.source, pic.likeCount, pic.downloadCount, pic.viewCount, pic.content, pic.uuid as id, tag.score, taglist.tagName from web_tags taglist left join web_worksTag tag on tag.tagId = taglist.id left join web_workItem pic on tag.workItemId = pic.uuid where pic.type != 0 and taglist.tagName like "%%" group by pic.uuid order by pic.featured desc, score desc limit 0, 20 ;
而Time,呵呵,好几分钟了,为什么这样呢,因为like %%,搜索图片的时候没有输入关键字就开始搜索了,明显这是个bug,先修复掉。如果没有keyword则返回错误。接着,继续通过 show full processlist; 优化。
接着发现State这里是 Sorting for order 因为这排序不好,于是给 score、featured 加了索引,诸如此类,那条语句慢则优化那条语句。最终,cpu占用率大幅下降,但波动很大,不过这也正常。
解决完cpu占用很高之后,却无意间因为一个事务处理中发生异常,导致事务没有提交,进而数据库被锁死,出现的错误如题。这部分的解决主要参考:https://blog.csdn.net/zc474235918/article/details/72731363 ,可通过如下sql查询并解决:
use information_schema; select * from innodb_locks; select * from innodb_trx; kill 421726928236952
这里 kill 后面的这串数字是 trx_id 对应的值。