其实可以使用MySQL内部的表定位问题SQL,通过这个SQL来定位问题,通过这个SQL的查询结果可以定位具体的SQL问题,然后再进行优化,而我的CPU偏大原因就是因为部分使用了like查询,优化这个部分mysql就正常了。
如果我们查看“top”命令的输出,我们会看到:MySQL 5.7
MySQL 8.0
这也展示出 MySQL8 使用的更多常驻内存和虚拟内存。特别是“可怕的”虚拟内存,因为它远远超过这些 VM 上可用的 1GB 物理内存。当然,虚拟内存使用(VSZ)是现代应用程序实际内存需求的一个很差的指标,但它确实证实了更高的内存需求这个事。
实际上,正如我们从 “vmstat” 输出中所知道的那样,即使没有太多的“空间”,MySQL 8 和 MySQL 5.7 都不会在低负载下使用 swap 分区。如果您有多个连接或希望在同一个 VM 上运行某些应用程序,则可以使用 swap(如果未启用交换,则可能导致 OOM)。
这是一个有趣的实验,能看看我有多少可以驱动 MySQL 5.7 和 MySQL 8 的内存消耗。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)