正确评估SQL数据库性能,你必须知道的原理和方法!

作者简介: Max Shen(阿特),为了成为数据专家而努力,万一实现了呢!

昨天写了一篇如何监视数据库性能,了解数据库的运行状态。被有人质疑,说没有用。说要直接用数据库的profile和monitor就可以了,到这一步那已经是到了数据库查询性能,已经到了调优的后期。对此我表示不认同,于是现在来写一个评估数据库的前言,谈谈数据库性能问题所需要了解的内容。

基本概念

性能问题

什么是性能问题?当系统出现性能问题,那么反过来问为什么说出现了性能问题,或者说到底怎么样算性能问题呢?

  • CPU100%,CPU占有率过高?CPU就算是100%,但是客户端反馈超快,算不算性能问题呢?
  • 剩余内存过低?操作系统剩余内存过低有可能是SQL吃完了,所以不一定。那如何知道SQL使用的内存情况呢?
  • 查询慢?查询慢,是否就是性能问题?如果一段存储过程写了500行,里面关联几十个表,有复杂的逻辑运算,执行一次超过3000ms,这是慢还是快呢?所以所谓的查询慢,也要有评估机制。
  • 查询链接超时?查询超时,链接超时就更复杂了,有n多因素影响。
  • …………

还有很多情况,客户都说性能问题。所以到底什么算性能问题呢?我个人认为是:

分为2种情况,第一是新系统运行与经验系统相差巨大,性能测试和压力测试不符合预期。第二种是正常运行系统发生与通常情况反映不一致状态,导致业务运行困难。

通常性能下降是我们说的性能问题,但是:

还有性能突然提升,比如平常打开页面3秒钟,突然什么都没有做变成了0.5秒。算不算性能问题呢?我认为也算性能问题,世界上绝对没有无缘无故的爱,也没有无缘无故的恨。所以突然的提升一定隐藏着更为重要的问题!

那么既然有了概念,有哪些关键指标来评估数据性能问题呢?有了指标,我们就需要收集指标,所以有昨天的文章。

衡量性能问题的关键指标

响应时间(Response Time)

响应时间一般指的是一条SQL 语句执行后得出结果耗费的时间。
而一般用户使用来说,比如BS结构,响应时间大家一般会认为是访问页面到页面呈现结束,这样的感官时间。这个时间就需要考虑更多的因素。比如网络、浏览器等等。曾经我碰到的CASE 页面打开速度超慢,但是数据库正常,后来分析发现是页面中潜入的一个很小的GIF影响了。所以要系统来分析。
而执行SQL语句获得的响应时间是最为纯粹的反馈,也是能够得到准备信息的步骤。
在系统跟踪的话,可以用SQL profile 来跟踪响应的内容,分析语句的反馈时间,之后再来详细讲解。

吞吐量(Thougput)

吞吐量是反映系统到底有多繁忙的指标,了解此指标可以更为清晰的知晓系统的使用状况。
性能监视器中可以用SQL Batch Request/Sec,SQL Transactions /Sec等指标来获取。

基线 (BaseLine)

BaseLine一直是我强调的指标。
基线是反映系统日常状况的指标,如果知晓了系统的各种基线值。那么就清楚了底在哪里,天在哪里。这样才能更容易去判断和解决问题。 而基线值是靠长期经验和数据获取的。

瓶颈(bottleneck)

系统一旦产生了瓶颈,我们就要去判断瓶颈,而瓶颈一般来说多会有关联性。比如内存不足可能导致IO过高,IO过高也可能导致CPU等待。
所以准确的知道瓶颈在哪里,这是需要去判断的。使用性能监视器和分析功能可以快捷的帮助大家分析瓶颈。

调优本质

调优的本质来讲,一般的调优都指的是性能出现过高,需要系统稳定的情况。所以本质来讲是干以下事情:

降低工作负载

  • 减少查询请求的数量:去除不必要的数据库访问
  • 降低查询请求的复杂度:优化查询逻辑的设计
  • 减少查询请求之间的依赖关系:优化事务的设计和并发性控制

优化系统资源的配置

  • 找出系统资源瓶颈,增加相应的资源
  • 优化系统资源的分配

性能优化的方法学

如下图,性能优化涉及的层面有:

  • 构架设计
  • 查询优化
  • 索引优化
  • 并发控制
  • 存储优化
  • 服务器优化
    相关优化的成效和收益还要顺序,可见下图:

这里写图片描述

优化的平衡

  • 优化是一个持续的过程,永无止境,解决了当前“最大”的瓶颈后,下一个“最大”的瓶颈又会出现
    要知道何时停止优化
  • 优化的内容应该是基于业务需求的优化
  • 关注二投资回报率(ROI) ,工程师的时间也是投入,因此要懂得投资回报,需要懂得停止优化!
  • 改变选项是最有意义的优化策略,有的优化是业务决定,那么无法改变的时候是否可以改变业务逻辑。
  • 实际上,足够好的性能就足够了。很多时候足够即可,而不是去寻找极限!

调优思路

调优思路来说,从理论上,在数据库构架时候就应该介入。但是通常我们遇到的情况都是半路出来。发生问题才找到DBA。所以遵循的思路可以是如下:

这里写图片描述

理解瓶颈,知道发生了什么,然后做优化配置,调整执行慢的语句。
然后再反复,反复。

总结

调优是个系统工程,要有敏锐的触觉,有可能一条参数改变整个系统感受。所以深入理解原理和方法,才能得心应手。 具体的方法,工具等敬请期待新的Blog。

展开阅读全文

没有更多推荐了,返回首页