在进行索引分析和SQL优化时，可以将数据索引字段想象为单一有序序列，并以

此作为分析的基础。

实战范例：复合索引查询优化实战，同城异性列表

资源： 用户表user，字段 sex性别；area 地区；lastlogin 最后登录时间；其他略 目标： 查找同一地区的异性，按照最后登录时间逆序

高访问量社区的高频查询，如何优化。

查询SQL: select * from user where area=’$area’ and sex=’$sex’ order by lastlogin desc limit 0,30;

挑战： 建立复合索引并不难， area+sex+lastlogin 三个字段的复合索引,如何理解？

首先，忘掉btree，将索引字段理解为一个排序序列。

如果只使用area会怎样？搜索会把符合area的结果全部找出来，然后在这里面遍历，选择命中sex的并排序。 遍历所有 area=’$area’数据！

如果使用了area+sex，略好，仍然要遍历所有area=’$area’ and sex=’$sex’数据，然后在这个基础上排序！！

Area+sex+lastlogin复合索引时（切记lastlogin在最后），该索引基于area+sex+lastlogin 三个字段合并的结果排序，该列表可以想象如下。

广州女$时间1

广州女$时间2

广州女$时间3

…

广州男

….

深圳女

….

数据库很容易命中到 area+sex的边界，并且基于下边界向上追溯30条记

录，搞定！在索引中迅速命中所有结果，无需二次遍历！

如何理解影响结果集

影响结果集是数据查询优化的一个重要中间数据

查询条件与索引的关系决定影响结果集

如上例所示，即便查询用到了索引，但是如果查询和排序目标不能直接在索引

中命中，其可能带来较多的影响结果。而这会直接影响到查询效率

微秒级优化

优化查询不能只看慢查询日志，常规来说，0.01秒以上的查询，都是不够

优化的。

实战范例

和上案例类似，某游戏社区要显示用户动态，select * from userfeed where

uid=$uid order by lastlogin desc limit 0,30; 初期默认以uid为索引字段，

查询为命中所有uid=$uid的结果按照lastlogin排序。 当用户行为非常频

繁时，该SQL索引命中影响结果集有数百乃至数千条记录。查询效率超

过0.01秒，并发较大时数据库压力较大。

解决方案：将索引改为 uid+lastlogin 复合索引，索引直接命中影响结果