（一） 在说数据库优化时，我们应该做些什么？
00 优化之前我们应该做什么？
在说给数据库做性能优化时，我们应该做些什么呢？
我们在优化之前一定要了解数据库内部原理吗？
要去不断调整数据库、操作系统的参数呢？
数据库的性能就只是数据库的架构决定的，跟应用、开发关系不大吗？
我们是不是必须遇到了瓶颈要做读写分离、分库分表呢？
NO!
其实，它们可能都是数据库优化的一部分，但既不是开始，也不是目的，更不是全部。
我们首先要搞懂，为什么要做数据库的优化？
从业务角度出发，是为了减少用户响应时间。
从数据库角度看，是为了减少数据库SQL响应时间。
从数据库的服务器角度来说，是为了充分使用数据库服务器物理资源，减少CPU、IO、内存的使用率。
我们在优化之前，一定要给出一个目标。
如
•响应时间变短，优化前数据库的平均响应时间是500ms，指定优化目标缩减到200ms。•CPU占用率变少，优化前高峰期使用率70%，优化后变成50%。•IO使用率变低，优化前IO WAIT 30%，优化后10%。•SQL执行时间变短，优化前1000条SQL执行为3600s，优化后降到200s。
还有其他诸如硬解析率、软解析率、TPS压测值，也都可以作为一个指标。
至于指标到底怎么定？我们接下来继续说。
01 做数据库优化有流程吗？
我们应该制定一个什么样的流程，来做数据库优化？
或者说，我们做数据库优化时，应该要经过一个什么流程呢？
如图：
1、我们首先应该了解待优化的问题；【到底出了什么问题？】
2、收集系统信息；【哪里出了问题？】
3、制定优化目标；【得到客户认可，解决什么问题？】
4、分析性能问题；【具体的问题在哪里？什么原因引起的问题？】
5、制定优化方案；【针对分析出的问题怎么去解决？】
6、实施优化方案；【谁来实施？怎么实施？有没有风险？】
7、判断是否达到优化目标；【效果怎么样？如果不行还需要重新分析问题。】
8、编写优化报告。【目标达到，我们要编写优化报告，告诉客户解决了什么问题。】
以上，便是我们数据库优化的一个大体流程。
接下来具体说说怎么做。
02 信息收集与目标制定
首先，我们要了解待优化的问题。
从哪里了解？用户、运维、开发人员等等。
我们一般能了解到什么信息？
用户一般会说应用访问慢、系统卡、打不开等等。
运维人员会说服务器的硬件资源占用率高，如CPU很高、内存不够了等等
开发人员会说接口总是报错，数据库响应时间变得很长，TPS、QPS压不上去。
那么，这些信息都是真实有效的吗？
我们在这里谨记一个守则：凡是“判断”、“分析”类的信息统统屏蔽，凡是“症状”、“表现”类的信息细细保留。
why？
因为别人的“判断”，特别是来自以上三类人群的“判断”，大部分是片面的，很可能会干扰你的思路，甚至会把你带到沟里去，让你对某些问题视而不见，导致做了大半天的无用功。
我们要有一套自己的优化思路。
在了解到当前待优化的问题后，我们紧跟着要干什么？开始优化吗？
当然不是。
而是最基本的，来到第二步，收集系统信息。并且尽可能全面地收集系统信息。
我们可以从业务、数据库、服务器等角度收集系统信息。分类保存，以便后期优化时使用。
然后才是我们前面章节所说的，制定优化目标。
怎么制定优化目标？
首先是分析数据库大概存在的瓶颈，然后是制定明确的优化目标（如业务、数据库、服务器等多种角度）。
最重要的是，优化前一定要跟客户沟通好，让客户确认本次优化的目标，得到认可。
再接着，就是具体地分析性能问题了。
03 问题分析
问题分析这一块可以说的内容太多了，所以单独放了一小节。
首先，我们可以采用自上而下的顺序进行分析。
操作系统（CPU、IO、NETWORK）-> 数据库实例-> 数据库对象-> SQL
对操作系统我们采用什么工具呢？我们现在的服务一般都是部署在Linux上的，所以我们一般使用以下这些工具进行检测。
•SAR•HTOP•NMON•TOP•ETHTOOL•……
那对于数据库，我们有什么工具来分析数据库的等待时间瓶颈呢？
•ORACLE：AWR、STATSPACK、内部视图、GRID CONTROL、STA、SAA、ADDM•MYSQL：慢日志、PERCONA TOOLKIT、MEM、内部视图……•SQLSERVER：SQL PROFILE、内部视图……•POSTGERS：pg_stat_statements、SQL trace……•达梦：AWR、内部视图、监控工具、SQL trace……
在使用上面的工具对操作系统、数据库进行信息收集、初步分析后，我们紧接着就要根据找到的瓶颈进行深入分析。
从哪些方面分析？
•操作系统参数是否配置合理？•数据库参数是否合理？•索引设计合理吗？•数据库有没有bug？排除下•捕获主要的问题SQL，对其进行深入分析•硬件资源是不是不足了？•数据库的选型是否恰当？•数据库表设计是不是合理？•是不是业务流程的设计存在问题导致的数据库性能问题？
从实际的优化经验来说，大部分的数据库性能问题都是由问题SQL导致的。而问题SQL的大部分起因都是索引设计不合理，甚至没有索引。
04 制定及实施优化方案
在找到问题原因后，我们怎么去制定并实施优化方案呢？
•数据库架构调优•数据库表结构优化设计•操作系统内核参数优化•数据库参数优化•添加或删除索引•改写SQL语句•调整应用流程•采用数据库高级特性•升级硬件•……
这些都是优化的方案，那我们怎么选择呢？
归根到底，还是要根据我们问题分析的结果去制定。一个完整的优化方案应该包含如下内容：
•1、背景；•2、问题现象；•3、分析过程及结论；•4、优化建议；•5、实施计划及风险。
我们例举一个案例，这个案例是oracle的。
1、背景
运维人员反应系统报表出不出来。
2、问题现象
XX系统经常夜里12点就刷不出来了，要等很长时间。
3、分析过程及结论
从整体ASH报告分析，数据库性能压力一般，但是特定时间的数据库问题比较明显，一般集中在晚上20:00-凌晨1:00左右。
某些SQL执行时间到达1000s以上。这类SQL必须优化。
4、优化建议
1）从AWR报告抓取问题SQL，提交开发修改。2）对log_XXX_detail等类似大表进行修改，调整字段类型，并对表进行分析。
5、实施计划及风险
基本无风险；但需应用配合，无需重启数据库。
在实施方案的时候，我们需要注意什么？
1、数据库实例优化方案应由运维人员及DBA实施;
2、SQL优化方案由开发人员修改应用措施；
3、任何类型的实施在操作前都需要做好计划及回滚方案。
05 编写优化报告
我们在优化完毕了，这个事情就结束了吗？
不！
我们还要对整体优化做出总结。
why？
因为我们要体现出优化的价值，并且为下次优化打好基础。
我们的报告要能明确体现出优化的效果。
优化报告怎么写？一般注意以下几个要素:
•1、数据库优化背景；•2、索引重建优化前后对比；•3、CPU使用率；•4、磁盘基线；•5、锁使用情况；•6、其他未尽之说明。
为什么要写优化报告？
一言以蔽之，这就是你工作中的业绩报告。如果干了活不被人知，不为人晓，那就是个傻把式。
升职加薪跟你有什么关系呢？
接下来举几个简单的优化报告的案例。
实例1：Oracle
某项目因IO资源不足导致数据库性能低下
数据库现象：CPU大量消耗
应用系统现象：大量IO等待、阵列IO不足
操作：购买新阵列、迁移数据库
效果：问题基本缓解
实例2：SQLSERVER
某项目数据库计算时间超过10小时
数据库现象：CPU和IO占用率较低
应用现象：系统基本空闲
操作：重新改写计算逻辑
效果：效率提升10倍以上
实例3：MYSQL
某项目数据库经常中断
数据库现象：主主模式经常出现数据不一致
应用系统现象：无明显特征
操作：调整架构为MHA模式
效果：数据库故障现象充分缓解
06 总结
梳理下本章我们学习的内容：
1、了解优化流程，收集问题信息。
2、优化流程的重点是问题分析这一步，要能通过科学的方法、便捷的工具，敏锐地发现系统瓶颈或者故障点；
3、优化可以从多个角度考虑，思路要开阔；
4、优化有大致的流程，但，是没有固定方法的。
07 后记
以上这一篇内容是数据库优化系列文章一篇，内容基本上是我在前公司的《数据库训练营》学习到的内容。
我觉得我遇到的这位老师说的很有道理。
其实问题并不可怕，怕的是不知道问题在哪？
问题也不难解决，难的是知道解决问题的方向。
仅以此希望跟大家分享。
后续的文章也会以oracle、mysql为主，从理论到实践，从方法到实战，来继续我们的数据库优化之路。
我的小专栏：https://xiaozhuanlan.com/topic/1273960485