重要的MySQL指标
作者：Katy Farmer / 用例，开发者
2017年12月18日
导航到
也许你还记得Blogger——不是那个看起来功能性强、设计精良的实际商业网站——而是我的爱好项目，一个完美结合了故障和低效，需要时刻监控的项目。Blogger不可信。请参阅我的第一篇关于它的帖子这里。
我们最初从表面开始，关注Blogger的请求数量。但Blogger不可能因流量过载而很快死去，所以我们不必担心它接收到的请求数量。让我们担心它的表现如何。
向主页添加更多内容已经让Blogger变慢了。最近的文章和最近的活动最终会加载……如果我不是那么投入Blogger，我不会等待。大多数用户也不会。想象一下，如果谷歌搜索结果需要30秒才能显示，你会怎么做。你会尝试Bing。因为最近的文章和最近的活动都需要从数据库中检索数据，现在是时候监控Blogger的数据库MySQL了。
首先，我们需要确定哪些指标值得监控。简单的网络搜索（简单到只有3个狗视频休息时间）显示MySQL输出的指标数量之多。太多了。如果我想，我可能甚至能找到它的曾祖母的名字和它小时候的第一只宠物。
但评估性能并不需要所有这些。有四个领域可以让我们了解MySQL：你不会相信第四个。开玩笑的——它们都非常有道理。
吞吐量
首先，数据库的任务是运行查询。它想要运行查询——如此之想，以至于它将运行你请求的任何数量的查询，无论负担如何，这可能在某些时候是个问题。MySQL有一些方便的状态变量，我们可以用它来检查：查询（服务器端）和问题（客户端）。
msql>SHOW GLOBAL STATUS LIKE "Questions"; +---------------+--------+ | Variable_name | Value | +---------------+--------+ | Questions | 282590 | +---------------+--------+ 1 row in set (0.00 sec)
msql> SHOW GLOBAL STATUS LIKE "Queries"; +---------------+--------+ | Variable_name | Value | +---------------+--------+ | Queries | 294564 | +---------------+--------+ 1 row in set (0.00 sec)
说实话，这些数字对我没有任何意义，但我能够确定它们是从数据库创建时开始的累计数。读取和写入的分解将更有帮助。猜猜谁有这些变量的？
<figcaption> 这是MySQL。MySQL有相应的变量。</figcaption>
Com-select显示读取操作，而Com-insert、Com_update和Com-delete的组合将显示写入操作（这些也是累计数）。
mysql> show global status like "Com_select"; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Com_select | 28854 | +---------------+-------+ 1 row in set (0.01 sec)
mysql> show global status like "Com_insert"; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Com_insert | 69317 | +---------------+-------+ 1 row in set (0.00 sec)
执行时间
如果查询量看起来正常，但瓶颈仍然存在，那么执行时间就是下一步。当然，博主可以处理所有的294564个查询，但如果其中一个查询需要五分钟才能完成，那就另说了。MySQL有一个名为Slow_queries的变量，你可以用它来进行快速检查。
mysql> show global status like "Slow_queries"; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Slow_queries | 0 | +---------------+-------+ 1 row in set (0.00 sec)
万岁！
当然，这不一定总是零。博主也没有慢查询，要么是因为我是一个超级程序员，要么是因为它实际上并没有做任何复杂的事情。谁又能说得清呢？
并发性
MySQL中的事务数量与同时发生的事务数量一样重要。让我们假设博主（再次强调，不是真正的商业博主，而是我的Frankenstein）已经成功了。它是博客的比特币（可能某个地方真的有一个商业提案）。
<figcaption> 加密博客是未来。</figcaption>
如果博主每秒接收20K个查询（因为这个场景中它非常受欢迎），来自其忠实用户的平均延迟为2毫秒（延迟基于我将在下一节中展示的查询），那么这将会有40个并发查询。但如果MySQL挂起100ms（让我们在这个场景中怪罪操作系统），那么就会影响到4K个查询。哇。
如果你想知道更多关于这是如何工作的信息，请阅读“Understanding MySQL internals”。非常有趣。
同样，MySQL想要帮助我们。另一个变量，又是一个MySQL的日子。&code;Threads_running&code;将显示当前运行的线程数，如果你想了解更多信息，你还可以检查“Threads_connected”和“threads_created”。
mysql> SHOW GLOBAL STATUS LIKE "Threads_running"; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | Threads_running | 1 | +-----------------+-------+ 1 row in set (0.00 sec)
利用率
这可以说是一种广义的说法：监控你的资源。具体来说，利用率是指资源忙碌的时间（或百分比）。对于数据库来说，这意味着每个连接忙碌的百分比（哦，如果你想看连接，有一个变量可以查看：“Connections”），或者数据库可达的时间。利用率在确定存在问题但不知道问题是什么时非常有用。
<figcaption> 我的资料显示有些不同。</figcaption>
MySQL可以帮助我们解决这个问题。它有很多这些指标总结在性能_schema数据库和sys数据库中（sys更适合人类阅读，如果你是人类的话）。使用sys数据库，我可以找到最慢的查询。
mysql> SELECT * FROM sys.statements_with_runtimes_in_95th_percentile;
输出虽然可以阅读，但可能会相当广泛。在你的机器上运行它看看会发生什么！
这是我在并发示例中找到每个模式平均运行时间的查询。blogger_test的检查时间是2123微秒，大约是查询从到达到完成的平均2毫秒。
mysql> SELECT schema_name
, SUM(count_star) count
, ROUND( (SUM(sum_timer_wait) / SUM(count_star))
/ 1000000) AS avg_microsec
FROM performance_schema.events_statements_summary_by_digest
WHERE schema_name IS NOT NULL
GROUP BY schema_name;
+---------------------+--------+--------------+
| schema_name | count | avg_microsec |
+---------------------+--------+--------------+
| blogger_development | 248834 | 149 |
| blogger_test | 188 |2123 |
| information_schema | 3 | 156 |
| performance_schema | 17 | 578 |
| sys | 8 |5437 |
+---------------------+--------+--------------+
5 rows in set (0.00 sec)
结论
在performance_schema中有很多惊人的指标可用，你应该在出现MySQL紧急情况之前花时间探索，这样你知道当SQL的冰冷之手来找你时该看哪里。
现在我们已经确定了哪些指标重要，我将继续探索MySQL。在我的下一篇文章中，我将具体讨论Blogger中的吞吐量、执行时间、并发性和利用率。
