微博MySQL优化之路

数据库是所有架构中不可缺少的一环，一旦数据库出现性能问题，那对整个系统都回来带灾难性的后果。并且数据库一旦出现问题，由于数据库天生有状态（分主从）带数据（一般还不小），所以出问题之后的恢复时间一般不太可控，所以，对数据库的优化是需要我们花费很多精力去做的。接下来就给大家介绍一下微博数据库这些年的一点经验，希望可以对大家有帮助。

硬件层优化

这一层最简单，最近几年相信大家对SSD这个名词并不陌生，其超高的IOPS在刚出现在大家视野中的时候就让人惊艳了一把，而随着最近价格的不断下调，已经非常具有性价比，目前微博已经把SSD服务器作为数据库类服务的标配。

我们来看下我们早些年自己对SSD的OLTP的性能测试：

然后通过explain具体分析慢查晓的问题所在

重点查看type，rows和extra这三个字段。

其中type的顺序如下：

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

最后，如果问题还是比较严重，可以通过show profiling来定位一下到底是那个环节出现的问题。

可以看到sending data最消耗时间，这时候就需要找到底为什么在sending上消耗了这么多的时间，是结果集太大，还是io性能不够了，诸如此类

以下就是一个复杂语句的优化结果，可以从rows那里明显的看出减少了很多查询的开销。

1. 通过mcq降低对MySQL的写入性能的要求。
2. 通过mc和Redis来承担用户的实际访问，90%的量依靠cache层承载和屏蔽。
3. MySQL作为最终的数据落地，存储全量的数据，但是仅支撑部分业务查询，小于10%。

经验：让合适的软件做适合的事情，不要光从技术层面思考优化方案，也要从需求方面去分解。

总结中的总结

转一篇很经典的数据库优化漏斗法则，很多年前就看到过，现在再看依然觉得适用，大家共勉。

唯一不适用的就是最下的增加资源，SSD真是个好东西，谁用谁知道。