当我们遇到数据库调优问题的时候，该如何思考呢？
整个流程划分成了 观察（Show status） 和 行动（Action） 两个部分。字母 S 的部分代表观察（会使用相应的分析工具），字母 A 代表的部分是行动（对应分析可以采取的行动）。
我们可以通过观察了解数据库整体的运行状态，通过性能分析工具可以让我们了解执行慢的SQL都有哪些，查看具体的SQl执行计划，甚至是SQL执行中的每一步成本计划，这样才能定位问题所在，找到了问题，再采取相应的行动。
首先在S1部分，观察服务器的状态是否存在周期性的波动，如果存在周期性波动，有可能是周期性节点的原因，比如双十一、促销活动等。这样的话，我们可以通过A1这一步解决，也就是加缓存，或者更改缓存失效策略。
如果缓存策略没有解决，或者不是周期性波动的原因，就需要进一步分析查询延迟和卡顿的原因，接下来进入S2这一步，我们需要开启慢查询。慢查询可以帮我们定位执行慢的SQL语句，我们可以通过设置long_query_time参数定义”慢“的阈值。如果SQL执行时间超过了long_query_time就会认为是慢查询。当收集上来这些慢查询后，我们就可以通过分析工具对慢查询日志进行分析。
在S3这一步中，我们就知道了执行慢的SQL，这样就可以针对性的用explain查看对应SQL语句的执行计划，或者使用show profile查询SQL中每一个步骤的时间成本。这样就可以了解SQL查询慢是因为执行时间长还是等待时间长。
如果是SQL等待时间长，进入A2步骤，这一步中我们可以调优服务器的参数，比如适当增加服务器的缓冲池等。如果SQL执行时间长，就进入A3步骤，这一步中我们需要考虑是索引设计的问题？还是查询关联的数据表过多？还是因为数据表的字段设计问题导致了这一现象，然后在这些维度上进行调整。
如果A2和A3都不能解决问题，我们需要考虑数据库自身的SQL查询性能是否已经达到了瓶颈，如果确认没有达到性能瓶颈，就需要重新检查，重复以上的步骤。如果达到了性能瓶颈，进入A4阶段，需要考虑增加服务器，采用读写分离的架构，或者考虑对数据库进行分库分表，比如垂直分库，垂直分表和水平分表等。
以上就是数据库调优的流程思路。
如果我们发现执行SQL时存在不规则延迟或卡顿的的时候，就可以采用分析工具帮我们定位有问题的SQL，这3重分析工具可以理解是SQL调优的三个步骤：慢查询、explain、show profiling。
