基本概念

性能问题

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

• 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。