分布式存储--Mysql--序列2--索引的设计策略

本人新书出版，对技术感兴趣的朋友请关注：

https://mp.weixin.qq.com/s/uq2cw2Lgf-s4nPHJ4WH4aw

索引设计一直是Mysql存储的核心部分，本篇将详细介绍设计索引过程中，要注意的一些基本策略。

在线计算转化成离线计算，减少索引个数

在通常用户量不是很大的系统中，我们会把C端的用户系统和内部用的运营系统混在一起，用一个库来查询。

但你会发现大多数查询条件，其实都只是内部运营系统才用得到，比如做各种复杂的报表查询。所以如果你可以把C端系统和内部运营系统分开，C端系统用在线计算的思路做，运营系统用离线计算的思路做，这将极大减少索引的个数。

而尽可能减少DB的索引个数，将极大增加性能，这对于用户规模很大的系统，尤其有用。

一般线上系统，用户查的维度通常也就两三个，如果你的表有很多的索引，那就要考虑设计上是否有问题。

那怎么把在线计算和离线计算分开呢？有很大种思路：

比如对于实时性要求不高的报表查询，你可以把mysql数据按小时、按天同步到hive上，做离线查询；

再比如可以新建一个表，通过监听Mysql binlog把线上数据写入此表（比如阿里开源的canal），在此表上建立很多的索引条件，做离线计算（这个虽然不是完全实时，但是秒级别）。

建索引的判断标准

不是说只要是查询条件，就要建立索引。索引建的越多，更新数据就越慢。那什么样的查询条件，才应该建索引呢？

区分度高的字段。一般来讲，有如下的一个公式（假设有一个字段column）：
distinct(column) / count(*) >= 0.1

比如你有一个枚举类型的字段，总共就才取5个值，那distanct(column) = 5；总记录条数为count(*) = 10万，那这区分度就很少，就不需要建索引。对于这种字段，全表扫描和根据索引查，通常性能上没有多大区别。

索引的最左匹配原则

对于组合索引，比如3个字段A, B, C，建了一个索引(A, B, C)。那么A, AB就不需要再建，(A, B, C)已经包含了A, 也包含了AB，但是不包含BC，也不包含AC。

所以在建组合索引的时候，顺序非常重要。