运行生产环境时你能想知道您你的数据库性能如何？它是否提供了适当的性能水平？我们如何衡量它？数据库性能是一个非常广泛的话题，这篇文章我们想深入探讨一下，并讨论在谈论数据库性能时要寻找什么。
如何定义性能？
我们必须问自己的第一个问题是：我们衡量数据库性能的单位是什么？这本身并不是一个容易回答的问题。
每秒查询数 (QPS)
显而易见的选择是使用每秒查询数或 QPS。数据库在给定的时间段内可以执行多少次查询？问题是一个查询与另一个查询不同。我们可以有插入、更新、选择。我们可以有使用索引甚至主键访问数据的简单查询，也可以有连接多个表的复杂查询。我们可以比较单个查询或特定的、精确控制的查询组合的性能，但仅此而已。
在现实世界中，工作负载会波动，要确定应该使用什么作为一组查询来比较不同配置版本之间的性能并不容易。在给定的时间内，您可能会想出一个查询组合，但如果您想在几个月后重复基准测试，很可能您将面临不同的查询组合，从而很难比较一段时间内的性能。
每秒事务数 (TPS)
这是另一种选择 - 我们可以在给定的时间段内执行多少笔交易？这种方法与使用 QPS 有很多相同的问题。事务中涉及的查询会随着时间的推移而改变，将引入新的事务类型。计算每秒事务数可能适用于给定时刻，但随着时间的推移很难比较结果。
延迟 (P99)
让我们尝试从另一个角度来处理这个话题。当我们谈论性能时，什么是最重要的？它是我们每秒可以执行的事务或查询的数量吗？如果您必须等待两倍的时间才能完成给定的查询，您是否可以将 QPS 提高 30%？你可能会问怎么可能？事实上，这很简单。您必须记住，在大多数情况下和大多数数据库中，一个查询只能使用一个 CPU 内核。是的，在某些情况下可以并行处理查询，但让我们坚持大部分工作负载。因此，一个 CPU 内核等于一个查询。这意味着，如果您运行的查询数量与您拥有的 CPU 核数一样多，那么您运行查询的速度将是最快的。这样我们可以最大限度地减少查询执行时间。另一方面，我们可以尝试最大化总吞吐量。可以想象，执行查询的过程不是最优的，也没有充分利用 CPU。如果我们开始排队并让 CPU 调度程序处理多个进程或线程，我们可以同时处理更多查询。由于这一点，我们可以显着提高吞吐量（以每秒查询数计算），但我们增加了查询的执行时间 - 现在每个线程必须与其他线程共享 CPU。因此，查询运行速度较慢，但我们仍然可以同时运行更多查询。由于这一点，我们可以显着提高吞吐量（以每秒查询数计算），但我们增加了查询的执行时间 - 现在每个线程必须与其他线程共享 CPU。因此，查询运行速度较慢，但我们仍然可以同时运行更多查询。由于这一点，我们可以显着提高吞吐量（以每秒查询数计算），但我们增加了查询的执行时间 - 现在每个线程必须与其他线程共享 CPU。因此，查询运行速度较慢，但我们仍然可以同时运行更多查询。
延迟也应该是可预测的 - 用户希望查询快速运行，但如果查询运行速度稍慢，如果这会提高查询执行时间的稳定性，那么他们可能没问题。这是因为如果用户不喜欢缓慢的应用程序，那就是应用程序间歇性地变慢并且没有充分的理由。增加吞吐量通常意味着延迟也会增加，但最重要的是，它可能会变得更加不稳定。
如您所见，这为我们的性能讨论增加了更多的复杂性。显然，用户希望他们的应用程序运行速度快且响应迅速（因此，我们希望延迟低）。另一方面，如果我们有很多用户，我们也希望能够同时运行许多查询（因此，吞吐量应该很高）。
如何改变数据库的性能？
我们已经写过关于如何衡量性能的文章，它有两个主要方面：延迟和吞吐量。另一个需要回答的重要问题是如何改变数据库性能？一般来说，我们谈论的是少数几种选择。
硬件改进
显然，性能与可用资源有关。如果我们改进运行数据库的硬件，它将影响数据库的性能。究竟有哪些改进，这取决于更改的内容以及我们正在查看的工作负载类型。简而言之，有两种主要类型的工作负载。
CPU 密集型工作负载
CPU 密集型工作负载是指性能受 CPU 资源限制的情况。我们在这里讨论的是活动数据集适合内存且磁盘活动最少的情况。它可能是由大量快速查询（例如索引查找）或少量长查询（涉及 JOIN 或排序和分组的重型分析查询）引起的。在这种情况下，通过添加更多内核或将 CPU 交换到每个内核提供更好性能的更新模型来提高 CPU 性能可以提高数据库的整体性能。
受 I/O 限制的工作负载
I/O 密集型工作负载是指我们在 I/O 子系统（通常是磁盘）上有大量负载的情况。这可能是由不同的情况引起的，但最常见的是这两种情况。首先，您的工作负载写入繁重，您在数据库中插入或修改了大量数据。结果，保存这些修改所需的写入量堆积如山，磁盘驱动器成为瓶颈。第二种最常见的情况是当您的活动数据集不适合您的记忆时。活动数据集是应用程序经常访问的数据库中存储的数据部分。请记住，您可以拥有比可用内存大得多的数据集，但只要数据仅保存在磁盘上，这不是问题。当数据库必须不断地从内存中交换数据来满足应用程序的需要时，就会出现问题。在这种情况下，我们观察到对磁盘的读取访问增加。
正如您所料，这两种类型的问题应该在硬件级别上以不同的方式解决。对于受 CPU 限制的流量，我们应该考虑通过提供更多 CPU 内核或提高每个内核的性能来增加服务器的计算能力，这通常是这种情况，尽管当您将 CPU 更改为较新的型号。如果我们谈论的是 I/O 密集型工作负载，我们可能有两种改进方案。首先，很明显，是提高磁盘子系统的性能。向 RAID 添加更多驱动器，使用性能更高的 RAID 级别（RAID 10 而不是 RAID 5 或 6），交换磁盘驱动器以提高性能。或者，如果您遇到大量读取的问题，您可以尝试增加可用内存：
配置调优
数据库有自己的配置，用户可以在其中调整一些设置以提高数据库的性能。有些设置可能更适合受 CPU 限制的工作负载，有些则更适合受 I/O 限制的工作负载。您可能听说过自动配置调整脚本或隐藏在 StackOverflow 或 Quora 中的 DBA 的秘密知识。现实情况是，除非您的数据库完全未配置，否则调整配置不太可能为您带来巨大的性能提升。是的，当然，你可能会稍微提高你的表现，但仅此而已。不要期望能够将您的数据库加速十倍。
查询调优
可以将性能提高十倍的是查询调优。以更有效的形式重写查询，添加缺失的索引。在这里，您可以看到巨大的好处，就像在网络上共享的不同监控工具的漂亮屏幕截图一样，您可以看到 CPU 利用率从 90% 以上下降到不到 10%。如果查询不必要地访问甚至数千行而使用适当的索引它只能访问一行，那么是的，这会显着加快速度。详细描述查询调优过程超出了本博文的范围，但要点是您应该收集与查询相关的指标 - 它们的执行时间、查询经历的等待、从数据库读取的行数, 发送到应用程序的行数。
数据越多越好，具体可以收集的数据取决于数据库类型，但大多数数据存储都提供与其查询相关的某种性能数据。如果您可以访问帮助您处理这些原始数据的工具，无论是内置软件还是外部软件，那就更好了。它应该可以帮助您更好地了解数据库中发生的事情、它的执行方式以及有问题的查询。
然后，作为下一步，您可能想要尝试了解有问题的查询的行为方式。通常，您可以访问某种查询执行计划 - 数据库优化器认为最佳的执行过程的详细概述。同样，不同数据库之间的细节有所不同，但我们在这里讨论的是如何访问给定数据，通过哪种方法，是否涉及任何索引，如果是，是哪些索引？如果我们在谈论关系数据库，您可能希望看到 JOIN 中表的顺序是什么，以及使用的 JOIN 方法是什么。这应该可以帮助您确定执行计划是否确实是最佳的，或者可能缺少一些潜在的改进。
一旦找出缺陷是什么，您可以尝试通过改进索引甚至将查询重写为更优化的形式来修复它。请记住，即使您使用的是无法修改的外部应用程序，在某些情况下，也有一些方法可以即时重写查询。通常它发生在负载均衡器级别。
衡量绩效
完成调整后，可以稍等片刻，看看该查询的最重要指标发生了怎样的变化。查询访问的行数是否较少？使用索引更好吗？它执行得更快吗？这几乎是衡量数据库性能的过程。您应该跟踪所有查询类型的延迟 p99。您应该跟踪所有查询类型的其他性能指标。
尝试调整查询，然后通过不断收集的指标，应该能够知道最重要的指标是如何变化的。延迟降低了吗？现在稳定了吗？给定查询类型在磁盘上存储了多少数据？相同的过程适用于硬件更改或配置调整。如果可以及时绘制 p99 延迟，就可以清楚地看到所做的更改是否影响了性能以及以何种方式影响？不论结果好坏？所以，秘诀非常简单——在数据库工作时一直收集性能指标。当决定进行更改时，将清楚地了解所引入更改的结果。
原文链接：https://severalnines.com/database-blog/how-measure-database-performance
