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

建议企业根据自身情况,整理出自己的业务压力模型.这在系统改造、升级、扩容评估、新硬件选型等多种场合都很有用处.它要比厂商提供的类似TPCC测试报告,更有意义.据我了解,很多规模较大的公司都有比较成熟的压力模型.

要想考察现有数据库能否承载增长后的业务压力,最好的方式就是模拟压力测试.观察在近似真实的压力下,数据库的表现.重点观察,数据库的承载力变化、主要性能瓶颈等.通常可以有两种方式,一种是从真实环境导流(并可根据需要放大流量,可利用类似TCPCOPY等工具);一种是根据前面整理的业务压力模型,通过压力工具模拟压力.前者适用于已有项目的扩容评估、系统改造评估等,后者适用于新上项目原型方案评估、性能基准测试等场景.

上述模拟压力测试结果中,暴露出的性能瓶颈点,就是我们后面需要着重改进、优化的方向.

针对上面的评估结果,来确定后面的改进、优化方案.可遵循如下一些步骤：

根据上面的评测结果,分析性能瓶颈点.针对不同瓶颈点,可采取不同的一些策略.有时候性能测试时全流程的,对于一个复杂系统来说,要明确定位到性能瓶颈点比较困难.此时,可借助一些APM工具,量化整个访问路径,协助找到瓶颈.也可以类似上面的做法,做好抽象工作,只对数据库端施加压力,观察数据库行为,判读数据库是否为瓶颈.如判断就是数据库的承载能力不够,可按照不同层次进行考虑.

在整个评估数据库承载能力中,这一步骤是最复杂的、也是最难的一部分.要区分清楚是否是数据库承载能力不足,还是其他组件的问题.即使明确是数据库的问题,也要分清楚是整体or局部的问题；是单一业务功能慢,还是整体都比较慢；是偶尔会慢,还是一直都很慢等等.这些问题的界定有助于后面明确问题层次,采取不同的策略进行解决.

针对数据库承载能力不足,我将常见出现问题进行了层次划分,可简单分为语句级、对象级、数据库级、数据库架构级、应用架构级、业务架构级.不同层次采取的方式也有所不同,下面分别描述一下.

如性能核心问题,只是某条SQL语句的问题,可有针对性地进行优化.这种方式是侵入性比较小的一种优化方式,其影响范围也比较小.下面对比常见的语句级优化方法.说明一下,下面方法已经排除了诸如统计信息不准确等其他因素,仅从SQL语句本身优化方式考虑.

• 改写SQL

通过改写语句,达到调整执行计划,提高运行效率的目的.这种方式的缺点是需要研发人员修改原代码,然后再进行部署上线的过程.此外,有些使用O/R Mapping工具产生的SQL,无法直接修改语句,也无法使用此方法.

• 使用Hint

很多种数据库都提供了提示(Hint)的功能.通过这种方式来指定语句的执行过程.这种方式同样需要修改源代码,经历部署上线的过程.此外,这种修改方式还存在适应性较差的问题.因为其指定了特有的执行过程,随着数据规模、数据特征的变化,固化的执行过程可能不是最佳方式了.这种方式实际上是放弃了优化器可能产生的最优路径.

• 存储概要、SQL概要、计划基线

在Oracle中还内置了一些功能,它们可以固化某一条语句的执行方式,从本质上来讲,其原理和上面使用Hint差不多.其缺点也类似上面.

• 调整参数

有时也可通过调整某些参数,进而改变语句的执行计划.但是这种方式要注意适用范围,不要在全局使用,避免影响较多的语句.在会话级使用也要控制范围,避免产生较大影响.

（编辑：网站开发网_马鞍山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!