mysql导致cpu占用趋近100%

还是之前做那个二级目录程序（二级目录租赁之iis反向代理设置方法），程序没有问题，只是对方要解析到xx目录，而不能解析到xx/目录，让我很疑惑，但没辙，得听人家的话，最终把相对路径改成了绝对路径。

程序已经上线了，但同时反映速度很慢，有的时候很卡，登录服务器发现cpu占用趋近100%，主要是mysql导致的。服务器配置应该还算可以（4核8G），所以直接看软件环境。首选看了一下mysql配置文件，发现tmp_table_size和max_heap_table_size都是32M，于是修改了一下，前者改成200M，后者改成500M，重启mysql，发现cpu占用只有不到10%了！

以为就这样就解决问题了，遗憾的是没有还没来得及高兴，cpu占用又上去了（刚才之所以下来，应该是刚重启mysql，网站的访问量不到，计算量不到）。

继续，登录mysql，执行show processlist，发现几条sql语句有很大问题：

select * from gk_temp where uid=44 order by rand() limit 1

这是自动发布（不了解自动发布的可以看这里：虚拟主机网站定时自动发布的思路与实现方法(php)），当有用户访问网站的时候从临时表随机取一条数据发布写入到正式表中，每个用户取一条。rand()本来就不好，而用户数越多，这样不好的语句就越多……本案用的是两张表，而不是如以往一样放在一张表中，通过特定字段来控制是否发布。之所以这样做，是因为用户每个时间段发布的内容都很相似，如果直接按顺序发布，那么新发布的内容很相似。所以就用了新表，随机取。

期初再做的时候没想到会有这么大的量，就用rand()凑合着用了，无奈只好修改一下，先试试不随机：

select * from gk_temp where uid=44 order by id desc limit 1

效果很明显，cpu直接降到了不到5%，但如前面所说，不是我期望的效果啊，还是得随机，继续改吧：

SELECT * FROM gk_temp AS u1 JOIN (SELECT ROUND(RAND() * ((SELECT MAX(id) FROM `gk_temp`)-(SELECT MIN(id) FROM gk_temp))+(SELECT MIN(id) FROM gk_temp)) AS id) AS u2 WHERE (u1.id >= u2.id and `uid`=44) ORDER BY u1.id LIMIT 1

效果一般，cpu占用在50%左右浮动，后台操作的时候还是会接近100%，因为后台发布数据的时候也有类似这样的sql。还有什么更好的随机查询语句呢？

百度了很久，也没有找到合适的解决方案，看来我的思路得改。

期初的程序是，针对每个用户随机取一条，发布。这样用户数越多，随机sql也就越多，效果是不错的，能保证每个用户实时都有数据发布，但性能是差劲的，改——不区分用户，直接随机所有数据，随机到谁就是谁了，为了让随机更随机一点（上面的语句随机出来的是连续的数据），换了一下sql，大概是这样，每次随机取n条，不区分用户来发布：

SELECT * FROM gk_temp WHERE id >= ((SELECT MAX(id) FROM gk_temp)-(SELECT MIN(id) FROM gk_temp)) * RAND() + (SELECT MIN(id) FROM gk_temp) LIMIT 5

没有后台操作（同事都下班了，悲催啊），mysql最高cpu占用10%左右，还行。

看来，鱼和熊掌有的时候真的需要取舍，思路也很重要，我们只能在效果与性能之前权衡。只是后台部分的数据查询好像没有办法更好优化，也没有其他思路可走了……先就这样吧，明天再看看有无可能

© 致远 2021-06-27，原创内容，转载请注明出错：mysql导致cpu占用趋近100%