单个表索引数量不宜过多
-
从上面分析我们知道，每个索引都对应一颗B+树，并且叶子节点存储了索引列全量的数据，一旦索引数量多，那么就会占有大量磁盘空间
-
同时前面也提到，在查询之前会对索引成本进行计算，一旦索引多，计算的次数就多，也可能会浪费性能
经常出现在where后的字段应该建立索引
这个就不用说了，索引就是为了加快速度，如果没有合适索引，就会全表扫描，对于InnoDB来说，全表扫描就是从聚簇索引的第一个叶子节点开始，顺着链表一个一个判断数据服不服合查询条件
order by、group by后字段可建立索引
比如下面这条sql
select * from `user` where name = '赵六' order by age asc;
查询name = '赵六'并且根据age排序，name和age联合索引。你可能记不清索树了，我把那个索引树拿过来。
此时对着索引树你可以发现，当name = '赵六'时，age已经排好序了（前面介绍索引的说了排序规则），所以就可以使用age索引列进行排序。
频繁更新的字段不宜建索引
因为索引需要保证按照索引列的值进行排序，所以一旦索引字段数据频繁更新，那么为了保证索引的顺序，就得频繁挪动索引列在索引页中的位置。比如name和age联合索引
此时把id=9这条数据的name从王九改成赵六，那么此时就把这条更改后的数据在索引页上移到王五和id=4的赵六之间，因为name相同时，得保证顺序性，同时要按照age排序，id=9的age为9，最小，那么排在最前。所以频繁更新的字段建索引就会增加维护索引的成本。
选择区分度高的字段做索引
这个是因为，如果区分度低，那么索引效果不好。举个例子，假设现在有个性别字段sex，非男即女，如果对sex建索引，假设男排在女之前，那么索引页的数据排列大致如下：
这里我画了6条数据，假设有10w条数据那么也是这继续排，男在前，女子在后。此时如果走sex索引，查询sex=男的数据，假设男女数据对半，那么就扫描的记录就有5w，之后如果要回表，那么根据成本计算规则发现成本是巨大的，那么此时还不如直接全表扫描来的痛快。所以要选择区分度高的字段做索引。
原文来自于三友的java笔记