【转载】数据库优化的几个阶段

原文连接：http://www.javashuo.com/article/p-uyslvsuc-gd.html

原文做者：孤独烟

引出

　　在面试的过程当中， 面试官常常会问:你是如何进行数据库优化的？那这个问题应该怎么答呢？其实写这个题材的缘由是我这几天看到各公众号转的一篇数据库调优的知识（不上连接了），我就稍微翻了几下，上面动不动就来讲要对数据库进行水平拆分，我就想反问各位读者，大家几我的经历过水平拆分?如今不少文章，实践性实在太差，只能说纯理论分析。
这篇文章最先来自知乎的一个提问，我在其基础上完善了一下。

第一阶段 优化sql和索引

这才是调优的第一阶段啊，为何呢？
由于这一步成本最低啊，不须要加什么中间件。你没通过索引优化和SQL优化，就来什么水平拆分，这不是坑人么。
那步骤是什么样呢?我说个大概
(1)用慢查询日志定位执行效率低的SQL语句
(2)用explain分析SQL的执行计划
(3)肯定问题，采起相应的优化措施，创建索引啊，等
我就不举例了，由于如何优化SQL的文章，一抓一大把，再贴过来，读者看着也累。

第二阶段 搭建缓存

在优化sql没法解决问题的状况下，才考虑搭建缓存。毕竟你使用缓存的目的，就是将复杂的、耗时的、不常变的执行结果缓存起来，下降数据库的资源消耗。
这里须要注意的是:搭建缓存后，系统的复杂性增长了。你须要考虑不少问题，好比:

• 缓存和数据库一致性问题？(好比是更缓存，仍是删缓存),这点能够看个人一篇文章《数据库和缓存双写一致性方案解析》。
• 缓存击穿、缓存穿透、缓存雪崩问题如何解决？是否有作缓存预热的必要。不过我猜，大部分中小公司应该都没考虑。这点能够看个人另外一篇《分布式之redis复习精讲》

第三阶段 读写分离

缓存也搞不定的状况下，搞主从复制，上读写分离。在应用层，区分读写请求。或者利用现成的中间件mycat或者altas等作读写分离。
须要注意的是,只要你敢说你用了主从架构，有三个问题，你要准备:
(1)主从的好处？
回答:实现数据库备份，实现数据库负载均衡，提交数据库可用性
(2)主从的原理?
回答:如图所示（图片不是本身画的，偷懒了）

主库有一个log dump线程，将binlog传给从库
从库有两个线程，一个I/O线程，一个SQL线程，I/O线程读取主库传过来的binlog内容并写入到relay log,SQL线程从relay log里面读取内容，写入从库的数据库。

(3)如何解决主从一致性?
回答:这个问题，我不建议在数据库层面解决该问题。根据CAP定理，主从架构原本就是一种高可用架构，是没法知足一致性的
哪怕你采用同步复制模式或者半同步复制模式，都是弱一致性，并非强一致性。因此，推荐仍是利用缓存，来解决该问题。
步骤以下:
一、本身经过测试，计算主从延迟时间，建议mysql版本为5.7之后，由于mysql自5.7开始，多线程复制功能比较完善，通常能保证延迟在1s内。不过话说回来，mysql如今都出到8.x了，还有人用5.x的版本么。
二、数据库的写操做，先写数据库，再写cache，可是有效期很短，就比主从延时的时间稍微长一点。
三、读请求的时候，先读缓存，缓存不存在(这时主从同步已经完成)，再读数据库。

第四阶段 利用分区表

说句实在话，大家面试的时候，其实能够略过这个阶段。由于不少互联网公司都不建议用分区表，我本身也不太建议用分区表，采用这个分区表，坑太多。
这里引用一下其余文章的回答:
什么是mysql的分区表？
回答：全部数据还在一个表中，但物理存储根据必定的规则放在不一样的文件中。这个是mysql支持的功能，业务代码不须要改动，可是sql语句须要改动，sql条件须要带上分区的列。
缺点
(1)分区键设计不太灵活，若是不走分区键，很容易出现全表锁
(2)在分区表使用ALTER TABLE … ORDER BY，只能在每一个分区内进行order by。
(3)分区表的分区键建立索引，那么这个索引也将被分区。分区键没有全局索引一说。
(4)本身分库分表，本身掌控业务场景与访问模式，可控。分区表，研发写了一个sql，都不肯定该去哪一个分区查，不太可控。
...不列举了，不推荐

第五阶段 垂直拆分

上面四个阶段都没搞定，就来垂直拆分了。垂直拆分的复杂度仍是比水平拆分小的。将你的表，按模块拆分为不一样的小表。你们应该都看过《大型网站架构演变之路》，这种类型的文章或者书籍，基本都有提到这一阶段。
若是你有幸可以在什么运营商、银行等公司上班，你会发现他们一个表，几百个字段都是很常见的事情。因此，应该要进行拆分，拆分原则通常是以下三点:
(1)把不经常使用的字段单独放在一张表。
(2)把经常使用的字段单独放一张表
(3)常常组合查询的列放在一张表中（联合索引）。

第六阶段 水平拆分

OK,水平拆分是最麻烦的一个阶段，拆分后会有不少的问题，我再强调一次，水平拆分必定是最最最最后的选择。从某种意义上，我以为还不如垂直拆分。由于你用垂直拆分，分红不一样模块后，发现单模块的压力过大，你彻底能够给该模块单独作优化，例如提升该模块的机器配置等。若是是水平拆分，拆成两张表，代码须要变更，而后发现两张表还不行，再变代码，再拆成三张表的？水平拆分模块间耦合性太强，成本太大，不是特别推荐。