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

核心提示： 这个查询有个问题：它有两个范围条件，MySQL会使用这两个条件的其中一个，Schema的优化和索引 - 学习一个索引示例(4)，但不能同时使用，如果last_online约束单独出现，如果未来的MySQL版本可以放宽索引的扫描，它应该做到在单独索引上使用多个范围查询，或者如果last_onlin

这个查询有个问题：它有两个范围条件。MySQL会使用这两个条件的其中一个，但不能同时使用。如果last_online约束单独出现，或者如果last_online的选择性多余age，我们可能希望添加另一系列的索引，要把last_online放在最后。但是，如果我们不能把age转为IN()列表，并且必须要在这两个条件同时出现来提高查询速度，怎么办？这种情况下，没有什么直接的方法，但是我们可以把一个范围条件转化为一个等值比较。为了这样做，我们添加了个active列，我们要周期性的维护它。当用户登录的时候我们会把这个列设为1，并且如果用户连续7天没有登录，会把它设为0。

这个方法可以让MySQL使用如(active, sex, country, age).这样的索引。这个列可能不是很精确，但是这种类型的查询要求的精确度低。如果我们需要精确地结果，我们可以在WHERE条件中加入last_online，当时不要索引它。这个方法有些像我们上几节说过的模拟HASH索引。这个条件不会使用任何的索引，但是因为它不太可能抛弃那些加上索引并没有太多好处的行。也就是说，没有索引也不太影响查询。

目前为止，你可能看到了一个模式：如果既想看活动的，也要看不活动的用户，我们可以添加IN()列表。我们已经添加了太多的列表了，但是可选择的是可以创建独立的索引来满足不同条件的组合。我们已经用了如下索引：(active,sex,country,age), (active,country,age), (sex,country,age), (country,age).虽然这些索引对于特有的查询都是最优的，但是就有维护的消耗，占有的空间，也可能使这种索引策略变得很失败。

这是个优化方式影响优化索引的例子。如果未来的MySQL版本可以放宽索引的扫描，它应该做到在单独索引上使用多个范围查询，因此我们也不必使用IN()列表了。