索引可以让服务器快速的定位到表的指定位置。但是这并不是索引的唯一作用，到目前位置可以看到，根据创建索引的数据结构不同，索引页有一些其他的附加作用。
最常见的B-Tree索引，按照顺序存储数据，所以MySQL可以用来做order by和group by 操作。因为数据是有序的，所以B-Tree也就会将相关的列值都存储在一起。最后，因为索引中村吃醋了实际的列值，所以某些查询只使用索引就能够完成全部查询。根据此特性，索引有以下三个优点：
① 索引大大减少了服务器需要扫描的数据量。
② 索引可以帮助服务器避免排序和临时表。
③ 索引可以将随机I/O变为顺序I/O
如果想深入理解索引推荐阅读有Tapio Lahdenmaki和Mike Leach编写的Relational Database Index Design AND THE oPTIMIZERS(Wiley出版社)这本书，书中详细介绍了如何计算索引的成本和作用、如何评估查询速度、如何分析索引维护的代价等
注意：索引不一定是最好的解决方案
总的来说，真自由当索引帮助村吃醋引擎快速查找到记录带来的好处大于其带来的额外工作时，索引才是有效的。对于非常小的表，大部分情况下简单的全表扫描效率更高。对于中大型的表，索引才是有效的。但对于特大类型的表，简历和使用索引的代价将随之增长。这种情况下，则需要一种技术可以直接群分出查询需要的一组数据，而不是一条记录一条记录的匹配。这就是分区。
如果表的数量特别多，可以建立一个元数据信息表，用来查询需要用到的某些特性。例如执行哪些需要聚合多个应用分布在多个表的数据查询，则需要记录那个用户的信息存储在哪个表中的元数据，这样查询时就可以直接忽略哪些不报汗指定用户信息的表。这对于大型系统，是一个常用的技巧。事实上Infobright就是使用类似的实现。对于TB级别的数据，定位单条记录的意义不大，所以京城会使用块级别元数据技术来替代索引。
例：
之前在一家小公司，由于项目是从外包做得，所以架构不是很好，一条常用的数据经常需要查询好几张表。后来给我提了一个需求要按天做一个产品的统计信息并用Echarts生成图表，这个产品分3~5个级别大概1000多个种类，几十万的数据量，当时的开始时间到结束时间的跨度是2年左右，要统计每个种类的数量并展示每个大类别的所占比例及每个种类的TOP5，这一系列查询大概涉及到5个表。所以我并没有使用建立索引的方式来做即时查询而是建立了一张新的汇总表，定时计算每个种类的数量信息，在拿这些数据进行简单的算数运算，每次页面刷新大概3~5秒左右，后来我又使用redis做了一次结果的缓存，这时候每次页面刷新耗时1~2秒。
这种处理是我当时能想到的最好的处理办法，也能满足一些后续可能出现的其他类似的需求。如果大家有更好的解决方案可以给我留言，共同进步。（产品表、产品类别表、产品详情表（名称在这里所以必须查）、出库表、入库表）。