正确评估SQL数据库性能，你必须知道的原理和方法！
作者：阿特 来源： http://blog.csdn.net/capsicum29/article/details/71480799
数据库是一个很重要的模块，现在来写一个评估数据库的前言，谈谈数据库性能问题所需要了解的内容。
基本概念
性能问题
什么是性能问题？当系统出现性能问题，那么反过来问为什么说出现了性能问题，或者说到底怎么样算性能问题呢？
- 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。