2015年1月30日：根据读者的反馈意见，第4节“您是否有足够的数据库连接？” 已修改。
数据库访问是大多数应用程序的核心功能。 根据我们的经验，对于我们看到的所有应用程序中至少有80％，简单的数据库性能调整可以显着加快应用程序的速度。
幸运的是，在您不了解数据库调优的情况下，并不会涉及很多火箭科学。 当您准备将数据库调优提高到一个新的水平时，可以使用许多不错的工具，例如来自Vivid Cortex的朋友。 但是，对于本篇文章，我们将仅着眼于无需第三方任何帮助即可轻松实现的快速胜利。
步骤1.您的数据库服务器是否健康？
首先，请确保为数据库进程提供服务的主机具有足够的可用资源。 这包括CPU，内存和磁盘空间。
*处理器
CPU很可能不是瓶颈，但是数据库服务器会在计算机上引起持续的基本负载。 为了使主机保持响应状态，请确保它至少具有两个可用的CPU内核 。
我将假定至少您的某些主机已虚拟化。 作为一般经验法则，在监视虚拟机时，还监视计算机在其上运行的虚拟主机。 单个虚拟机的CPU指标不会向您显示完整情况。 CPU准备时间之类的数字尤为重要。
将CPU时间分配给虚拟机时，CPU准备时间是一个重要因素
记忆
请记住， 内存使用并不是唯一需要注意的指标。 内存使用情况不会告诉您可能需要多少额外的内存。 要查看的重要数字是每秒的页面错误数 。
当谈到主机的内存需求时，页面错误是真正的指示
每秒有成千上万的页面错误表明您的主机内存不足（这是您开始听到服务器的硬盘驱动器耗尽的时候）。
磁盘空间
由于索引和其他性能的提高，数据库占用的磁盘空间比实际数据本身所需的磁盘空间还要多（索引，您知道）。 特别是NoSQL数据库（例如Cassandra和MongoDB ）占用的磁盘空间比您预期的要多得多。 与普通的SQL数据库相比，MongoDB占用的RAM更少，但这是真正的磁盘空间消耗。
我不能太强调这一点：确保硬盘驱动器上有很多可用磁盘空间。 另外，请确保您的数据库在专用硬盘上运行，因为这样可以将其他进程引起的磁盘碎片降到最低。
磁盘延迟是硬盘驱动器过载的指标
磁盘延迟是一个值得关注的数字。 根据硬盘驱动器负载，磁盘延迟将增加，从而导致数据库性能下降。 您能对此做什么？ 首先，尝试尽可能利用您的应用程序和数据库的缓存机制。 没有更快，更划算的移动针头的方法。
如果仍然不能达到预期的性能，则可以随时添加其他硬盘驱动器。 只需镜像硬盘驱动器，即可提高读取性能。 使用RAID 1或RAID 10而不是RAID 6确实可以提高写入性能。如果您想弄清楚这个问题，请阅读磁盘延迟和I / O问题 。
步骤2.谁在访问数据库？
一旦数据库驻留在健康的硬件上，您应该查看哪些应用程序实际上正在访问数据库。 如果您的应用程序或服务之一遭受了数据库性能不佳的困扰，请不要得出这样的结论：您知道哪个应用程序或服务是性能不佳的原因。
知道哪些服务可以访问数据库对于查找数据库性能瓶颈至关重要
在谈论劣等的数据库性能时，您实际上是在谈论两种不同的事物。 一方面，整个数据库可能会受到影响。 另一方面，数据库可能只是性能不佳的单个服务。
如果所有数据库客户端的性能都不好，请返回并检查主机是否真正正常。 您的硬件可能无法应对挑战。 如果只有一个服务的数据库响应时间很短，请更深入地研究该服务的指标，以找出导致问题的原因。
步骤3.了解每种服务的负载和个别响应时间
如果单个服务的数据库性能较差，则应更深入地研究该服务与数据库的通信。 执行哪些查询？ 每个请求多久执行一次查询？ 他们返回多少行？
您现在应该哪种类型的命令对数据库性能的影响最大
重要的是要知道，在数据库级别出现的问题可能植根于其他地方。 通常，存在与数据库访问方式有关的问题。
查看每个请求调用查询的频率。 也许您可以通过改善服务的数据库缓存来减少实际数据库查询的数量。 质疑一切。 是否有任何原因导致每个请求应多次执行单个查询？ 如果有的话，也许您可以通过应用智能缓存策略来释放一些潜在的性能。
步骤4.您是否有足够的数据库连接？
即使您查询数据库的方式非常好，您仍然可能会遇到劣等的数据库性能。 如果是这种情况，是时候检查应用程序的数据库连接大小是否正确。
检查“连接获取”时间是否占数据库响应时间的大部分。
配置连接池时，需要考虑两件事：
- 数据库可以处理的最大连接数是多少？
- 您的应用程序所需的正确大小的连接池是多少？
为什么不将连接池大小设置为最大？ 因为您的应用程序可能不是连接到数据库的唯一客户端。 如果您的应用程序占用了所有连接，则数据库服务器将无法正常执行。 但是，如果您的应用程序是连接到数据库的唯一客户端，那就去吧！
如何找出最大连接数
您已经在步骤1中确认数据库服务器运行状况良好。 与数据库的最大连接数取决于数据库上的资源。 因此，要找到最大的连接数，请逐渐增加负载和数据库允许的连接数。 在执行此操作时，请注意数据库服务器的指标。 一旦达到极限（CPU，内存或磁盘性能），您就知道已经达到极限。 如果达到的可用连接数量不足以支持您的应用程序，那么该考虑升级硬件了。
确定应用程序连接池的正确大小
允许的并发数据库连接数等于应用程序对数据库服务器施加的并行负载量。 这里有可用的工具来帮助您确定正确的数字。 对于Java，您可能想尝试一下log4jdbc 。
即使数据库服务器运行状况良好，负载增加也会导致事务响应时间增加。 从端到端测量事务响应时间，以查看连接获取时间在重负载下是否占用了越来越多的时间。 如果是这样，则说明您的连接池已耗尽。 如果没有，请再次查看数据库服务器的指标，以确定数据库可以处理的最大连接数。
顺便说一句，这里要记住的一个好的经验法则是，连接池的大小应该是恒定的，而不是可变的。 因此，将最小和最大池大小设置为相同的值。
第5步。不要忘记网络
我们往往会忘记虚拟化基础架构所面临的物理限制。 但是，仍然存在物理限制：电缆故障且路由器损坏。 不幸的是， 有效与无效之间的差距通常会有所不同。 这就是为什么您应关注网络指标的原因。 如果在几个月甚至几年的无故障运行之后突然出现问题，则您的基础结构很可能会遭受非虚拟的物理问题的困扰。 检查路由器，电缆和网络接口。 最好在出现问题的第一个迹象后尽早执行此操作，因为这可能是您在问题解决之前就可以解决问题的时间点。
重传严重影响网络性能
通常，过度紧张的进程会由于资源耗尽而开始丢弃数据包。 以防万一您的网络问题不是硬件问题，在识别出故障组件时，绝对可以使用过程级别的可见性。
数据库性能总结
数据库是复杂的应用程序，并不是为降低性能或故障而构建的。 确保数据库被安全地托管和分配资源，以使其发挥最佳性能。
这是优化数据库所需要的：
- 服务器数据以检查主机运行状况
- 虚拟机监控程序和虚拟机指标可确保您的虚拟化正常
- 应用程序数据优化数据库访问
- 网络数据分析数据库通信对网络的影响。
有许多工具可以为您提供此信息。 我在这里使用ruxit作为示例，因为它在一个工具中提供了我需要的所有数据。 虽然，显然，我有点偏见。
翻译自: https://www.javacodegeeks.com/2015/02/five-easy-steps-improve-database-performance.html