具有高CPU和“内核时间”使用的MySQL服务器

Question

我注意到一个mysql服务器的CPU为100％，“内核时间”（我不确定它是什么意思）异常高，大约70％。

此服务器上有许多连接（大约400个）和一些活动查询（大约40个）。这可以解释这种行为吗？有什么不对或有预料吗？

修改

根据评论的建议，我检查了'handler_read％'变量： show global status like 'handler_read%'。结果如下：

Handler_read_first          248684
Handler_read_key            3081370400
Handler_read_last           83333
Handler_read_next           3520958058
Handler_read_prev           330
Handler_read_rnd            2210158755
Handler_read_rnd_deleted    60107588
Handler_read_rnd_next       929907565

完整的show status和show variables结果如下： https://www.dropbox.com/s/98pnd1rzgfp4jtf/server_status.txt?dl=0 https://www.dropbox.com/s/rh0m8np0mosx6tp/server_variables.txt?dl=0

Answer 1

handler_read_rnd * 的高值表示您的表未正确编入索引，或者您的查询未编写以利用您拥有的索引。

由于系统调用开销和上下文切换，表扫描使用更多CPU。

在更改参数或在硬件上投入资金之前，我建议您优化数据库：

• 在有限的时间内激活慢查询日志（另外您可以指定参数log_queries_not_using_indexes和min_examined_row_limit）（慢查询日志的大小可能会非常快）。
• 使用EXPLAIN或EXPLAIN EXTENDED分析查询日志中的查询
• 如果生产服务器上出现问题，请先将内容复制到测试系统

Answer 2

许多设置太高或太低......

• tmp_table_size和max_heap_table_size是16G - 这是灾难性的！每个连接可能需要其中一个或多个。将其降低至RAM的1％。
• 有大量Com_show_fields - 向第三方供应商投诉。
• Created_tmp_disk_tables的大号码 - 这通常意味着索引编制或查询设计不佳。
• Select_scan / Com_select = 77％ - 缺少很多索引？
• Threads_running = 229 - 他们可能互相绊倒。
最近运行了
• FLUSH STATUS，因此某些STATUS值无效。
• table_open_cache是256 - 有一些迹象表明数字越多越好。试试1500。
• key_buffer_size只占RAM的1％;把它提高到20％。

仍然，......高CPU意味着索引不佳和/或查询设计不佳。让我们看看其中的一些，以及SHOW CREATE TABLE。