Schema的优化和索引 - 学习一个索引示例

核心提示：用例子来理解索引的概念是再简单不过的方法了，因此我们研究一个索引示例，Schema的优化和索引 - 学习一个索引示例，假使我们要做一个在线约会的网站，用户的资料就会有很多列，重要的是，添加这一列也不会有什么弊端，比如country, state/region, city, sex, age, eye color等等，这

用例子来理解索引的概念是再简单不过的方法了。因此我们研究一个索引示例。

假使我们要做一个在线约会的网站。用户的资料就会有很多列，比如country, state/region, city, sex, age, eye color等等。这个站点必须支持这些属性的组合来查询用户资料。也必须支持让用户通过用户最近的在线时间，其他会员的打分等等来排序和限制结果。对于这么个复杂的需求我们怎样来设计索引？

奇怪的是，第一个要决定的就是我们是否必须使用索引排序或者文件排序是否是可接受的。基于索引的排序限定了索引和语句创建的方式。比如，我们不能使用索引的情况是WHERE条件的age在18-25之间，不管语句是否使用了一个索引去排序。

如果MySQL使用了索引的范围查询，它也就不能使用另一个索引来排序了。假如这是个比较常见的查询，我们就得知有很多查询都要用到文件排序。

支持多种类的过滤

现在我们需要知道列具有唯一值的数量以及那些经常出现在WHERE条件后的列。在具有许多唯一值的列创建索引，这样做选择性很高。因为MySQL会高效的过滤掉不需要的值。

country不确定是否具有选择性，但是它可能会在大部分查询语句中出现。SEX列不具有选择性，但是它基本会在每个查询语句中出现。根据以上的想法，我们可以使用前缀为（sex,country）来创建一系列不同组合的索引。

按照传统的思路来说，在选择性低的字段加索引没有什么效果。但是我们为什么把一个选择性低的列放在每个索引的开始部分呢？思路错误了？

我们有两个理由要这么使用。第一个理由就是每个查询都会用到sex。我们甚至可以设计让用户仅能通过一个sex来进行搜索。重要的是，添加这一列也不会有什么弊端，因为我们还有一些技巧在里面。