监控 MySQL 性能指标和管理数据库并不困难。是的，你没听错。有了适当的监控策略和工具，您终于可以退居二线了。 RED 方法与 Releem 强大的监控功能和易于应用的配置建议相结合，可以为您完成繁重的工作。
RED 方法传统上用于监控 Web 应用程序和服务的性能，但也可以应用于 MySQL 性能监控。 Releem 发现该框架在监控 MySQL 性能指标方面同样有价值，因为数据库在性能和可靠性方面面临的挑战反映了 Web 应用程序遇到的挑战。
当应用于 MySQL 数据库时，RED 方法分为三个关键关注领域，每个领域都提供有关数据库运行状况的见解：
查询率（Rate） – 这评估每秒执行的查询或命令的数量，提供服务器工作负载的直接测量。它有助于评估数据库处理并发操作的能力及其对用户需求的响应能力。
错误率（Errors） – 跟踪查询中的错误频率可以揭示数据库中潜在的可靠性问题。高错误率可能表明查询语法、数据库模式或影响整体数据库完整性的系统约束存在潜在问题。用于监控速率的主要 MySQL 指标是 Aborted_clients。
查询执行持续时间（持续时间） – 持续时间指标是查询完成（从启动到执行）所需时间的度量。该性能指标评估数据检索和处理操作的效率，这对用户体验和系统吞吐量有直接影响。
这些指标的运行状况可以让您深入了解数据库的性能，进而了解用户的体验。 RED 方法可以轻松判断数据库出了什么问题以及需要修复什么。例如，如果您发现查询执行缓慢，则可能表明需要调整索引或优化受影响的查询以提高效率。
为了有效地将 RED 方法应用于 MySQL 性能监控，Releem 着眼于数据库的八个关键方面。其中每一项都以某种方式与速率、错误或持续时间联系在一起：
延迟测量执行查询所需的时间 - 从查询发送到数据库的那一刻到数据库响应。延迟直接影响用户如何看待您的应用程序。
对于大多数 Web 应用程序来说，实现数据库操作的延迟在几毫秒到大约 10 毫秒范围内被认为是非常好的。此范围可确保无缝的用户体验，因为最终用户几乎察觉不到延迟。
对于简单到中等复杂的查询，一旦延迟达到 100 毫秒或以上，用户就会开始注意到延迟。在即时反馈至关重要的情况下，例如在表单提交、搜索查询或动态内容加载中，这可能会成为问题。
有关 MySQL 延迟的更多信息
吞吐量，量化为每秒查询数 (QPS)，衡量数据库的效率及其管理工作负载的能力。高吞吐量意味着经过良好优化的数据库系统可以有效地处理大量查询。低吞吐量可能表示性能瓶颈或资源限制。
实现高吞吐量通常涉及优化的 SQL 查询、适当的硬件资源（CPU、内存和快速 IO 子系统）以及微调的数据库配置的组合。
有关吞吐量的更多信息
慢查询本质上是违反预定义执行时间阈值的数据库请求。您可以调整此阈值以适应您的特定性能目标或操作基准。跟踪慢速查询的数量是您识别需要优化的查询的方法。
这些慢速查询的识别和记录发生在 Slow_query_log 中，这是一个专用文件，用于存储有关无法满足设定性能标准的查询的详细信息。
有关慢查询计数的更多信息
此指标计算由于客户端未正确关闭连接而中止的连接数。大量中止的客户端可能表明了一系列原因：
有关中止客户端的更多信息
CPU 是服务器的大脑。它执行命令并执行计算，允许数据库存储、检索、修改和删除数据。密切关注 CPU 使用情况有助于确保服务器有足够的处理能力来处理其工作负载。高 CPU 使用率可能是服务器过载而难以满足其需求的明显迹象。
以下是一些关于 CPU 使用情况需要考虑的一般准则：
50-70% 持续 – 在此级别，您的 CPU 可以有效处理中等到重的工作负载，但仍有一些峰值负载的空间。对于正常运行的服务器来说这是一个健康的范围。
70-90% 持续 – 当 CPU 使用率持续在此范围内时，表明工作负载较高，为处理峰值需求留下的空间有限。您应该密切监控服务器。
持续超过 90% – 这是服务器接近或达到其容量的有力指标。可能会出现明显的性能问题，包括查询响应时间慢和潜在的超时。调查原因并相应地实施优化或扩展资源至关重要。
注意： 偶尔高于这些阈值的峰值不一定表示存在问题，因为数据库旨在处理可变负载。关键词是持续。持续高使用率表明您的服务器承受着巨大的压力。
RAM 是数据库的关键资源，因为它存储活动数据和索引，允许快速访问和高效的查询处理。正确管理 RAM 使用可确保数据库能够有效处理工作负载，从而优化数据检索和操作操作。
以下是 RAM 使用时需要考虑的一些一般准则：
– 此范围通常被认为是安全的，表示有足够的内存可用于当前数据库操作和额外的工作负载峰值。
70-85% 利用率 – 当 RAM 使用率持续落在该范围内时，表明数据库正在充分利用可用内存，但开始达到需要仔细监控的阈值。在高峰时段保持在这个范围内可能会限制处理需求突然增加的缓冲区。
85-90% 利用率 – 在此范围内，服务器接近其内存容量。当系统开始与磁盘交换数据时，高内存利用率可能会导致磁盘 I/O 增加。将此视为一个警告信号，表明需要优化工作负载或需要扩展服务器的物理内存。
> 95% 利用率 – RAM 使用率达到或超过 95% 时至关重要，可能会导致性能问题。在此级别，服务器可能会频繁地诉诸交换，从而导致严重的速度减慢，并可能导致客户端应用程序超时。您需要立即采取行动。
当数据库的物理 RAM 被充分利用时，就会使用交换空间，允许系统将一些不常访问的数据卸载到磁盘存储。虽然此机制有助于缓冲内存不足错误，但由于访问时间比 RAM 慢得多，依赖 SWAP 可能会严重影响性能。
理想情况下，MySQL 服务器应该表现出低至最低的 SWAP 使用率。这表明数据库正在其可用 RAM 内运行。
高 SWAP 使用率是一个危险信号，表明服务器的物理内存不足以满足其工作负载，迫使其依赖磁盘空间来进行日常数据操作。您应该立即采取措施解决这个问题，通过优化应用程序的内存需求或扩大服务器的 RAM。
每秒输入/输出操作数 (IOPS) 指标指示数据库与其底层存储系统（又称磁盘）交互的密集程度。高水平的 IOPS 意味着在存储介质之间传输的数据负载很重，这虽然表明数据库繁忙，但也可以突出磁盘性能的潜在瓶颈。
影响 IOPS 的一些关键因素包括：
Releem 的 MySQL 性能监控方法是密切关注重要细节。该策略包括对提到的 8 个指标进行认真跟踪——MySQL 延迟、吞吐量、慢速查询、中止的客户端、CPU、RAM、SWAP 使用情况和 IOPS——所有这些都在 RED 方法的框架内。通过将此监控集成为每日两次运行状况检查（19 个指标！）的一部分，Releem 可以帮助您的数据库实现并保持高水平的性能、可靠性和可扩展性。
除了密切关注 MySQL 性能之外，Releem 还进一步提供量身定制的配置建议，旨在修复监控过程中发现的任何问题。我们将此功能称为 Autopilot for MySQL。例如，如果您遇到高延迟问题，Releem 将提供可操作的见解，使您的延迟数字恢复正常。我们的最终目标是通过强大、直观的软件消除手动监督的需要，该软件可以处理您不想担心的所有数据库管理复杂性。
Releem 具有广泛的兼容性，因此无论您使用 Percona、MySQL 还是 MariaDB 作为数据库管理系统 – Releem 都可以提供帮助。在此处查看受支持系统的官方列表。
要深入探索 MySQL 数据库监控和优化的每个指标和最佳实践，请考虑访问 Releem.com。
以上是掌握 MySQL：每个开发人员都应该监控的关键性能指标的详细内容。更多信息请关注PHP中文网其他相关文章！
