解DBA之惑：数据库承载能力评估及优化手段

作为DBA，有时会被挑战类似这样的问题：

• 如果现有业务规模增加10倍、100倍，数据库是否能够支撑？
• 下个月我们搞大促，数据库这边没问题吧？
• 计划进行去O工作，代码逻辑不变，数据库从Oracle切换到MySQL，MySQL能支撑业务吗？
• 服务器采购选型，到底哪款服务器更适合我们呢？

面对诸如上面的这些质疑，DBA应该如何面对？

身为DBA该如何评估现有资源使用情况？

如果现有数据库资源确实无法支撑，又该本着什么原则进行改造呢？

本文是针对上面问题的一些经验总结，供大家参考。

一、评估工作

面对这样的问题，首先要进行评估工作，可遵循下面的步骤：

1、建立性能基线

针对系统运行现状，建立性能基线。将业务指标与性能指标建立起对应关系。这里所说的性能指标包括CPU、MEM、DISK、NET等。在诸多资源中，肯定存在不均衡的情况，短板的资源最有可能成为业务增长后的瓶颈。在具体操作上，可首先确定一个业务高峰时间段，通过监控平台或监控工具收集系统各资源的使用情况。然后依据收集的信息，分析可能的性能短板在哪里。

对于DBA来说，对自己掌管系统的性能使用情况要了然于胸。通过对业务的了解，将业务指标映射到性能指标上，就可以很容易地推断出现有系统可承载的最大业务量。此外，对于可能影响承载业务增长的短板，也会有比较清晰的认识。

一般来说，数据库类的应用是重资源消耗类的应用。对CPU、MEM、DISK、NET等，均有较大的消耗。但由于不同硬件发展水平不均衡，各数据库资源消耗特点也不同，因此需要具体问题具体分析。

下面谈谈我对硬件发展及与数据库关系的一点个人观点:

• CPU

相对于其他硬件而言，CPU技术发展较快。随着CPU主频提高及多核CPU技术的发展，CPU提供的计算能力往往不会成为系统的性能瓶颈。但我们需要注意的是，有些数据库是无法完全利用CPU的能力(例如MySQL就是这样)。此时，为了充分利用CPU的资源，可以考虑诸如"多实例混跑"的方案，提高CPU利用率。

• MEM

随着内存技术的发挥，内存的价格越来越便宜。现在我们在生产环境中，可以见到128、256GB，甚至TB级的内存也不罕见。一般来说，数据库通常会利用内存作为缓冲区，大内存的配置对数据库的性能有着比较明显的提升。此外，数据库自身技术也在适应着大内存的场景，通常采用的策略是划分子池。将管理的单位进一步细分，例如Oracle中的Sub Pool、MySQL中的多instance buffer pool。

• NET

随着GigE、10GbE、InfiniBand技术的飞速发展，低延迟、高带宽的服务品质给数据库乃至整个IT系统带来了