索引长度
索引长度短，区分度就低，索引长度长，区分度高，查询效率高，但是索引要占内存，所以要找到一个平衡点；
举个例子： （张，张三，张三哥），如果索引长度取1的话，那么每一行的索引都是 张 这个字，完全没有区分度，结果这样三行完全是随机排的，因为索引都一样；如果长度取2，那么排序的时候至少前两个是排对了的，如果取3，区分度达到100%，已经提前排序；
有一些特殊的字段比如url，绝大部分的url都是 http://www. 开头的，这种情况下索引长度取取到11都是无效的，需要更长的索引，那么有没有优雅的方式来解决呢；
第一种方法： 可以将数据倒序存入数据库；
第二种方法：对字符串进行crc32哈希处理；
建立索引
在多个Where条件的时候，会优先采用rows最少的索引。如果多个Where条件查询很频繁，则将where中所有字段加到联合索引。
注意：
- 数据区分度低的不应建立索引，比如sex就0、1，即区分50%。一般若rows大于总数据条数20%，则数据库走全表扫描。
- 如果该表大部分是单条查询，则应使用hash索引，因为B-Tree索引时间复杂度O(log(n)),Hash索引为O(1)。
- where子句的查询条件里有 != ，索引将无效。可以优化为in(xx, xx)
- where子句使用了sql函数的时候，索引将无效，比如：
select * from tb where YEAR(data) < '2017'; 可优化为 data < CURDATE() - LIKE查询必须是前缀固定的，否则无法使用索引。如：Title%可以使用索引，%Title和%Title%不能使用索引。
- 索引列尽量避免NULL，应该指定列为NOT
NULL或设置默认值。在MySQL中，含有NULL值的列很难进行查询优化，因为它们使得索引、索引的统计信息以及比较运算更加复杂。索引不存Null值，所以会导致 SELECT * FROM tb WHERE name != ‘xxx’ 不会返回name为Null的数据。 - 对于复合索引(key1, key2)，
select * from tb where key1 = xxx and key2 = xxx或select * from tb where key1 = xxx会走复合索引，而select * from tb where key2 = xxx不会走复合索引。即最左前缀匹配。 - 当你需要在一篇大的文章中搜索一个词时，如： “WHERE content LIKE
‘%apple%’”，索引是没有意义的，这需要全文索引。InnoDB引擎对FULLTEXT索引的支持是MySQL5.6新引入的特性，可对CHAR、VARCHAR、TEXT类型的列创建全文索引，全文搜索的语法：MATCH(col1,col2,…) AGAINST (expr[search_modifier])，默认情况下全文搜索大小写不敏感。 - 不要触发强制类型扫描，比如 select * from tb where phone = 18812345678，其中phone为varchar，这不会走索引。
- 在col_1和col_2上建立索引，不要
select * from tb col_1=2 or col_2=2，应优化为select * from tb where col_1=2 union select * from tb where col_2=2。
索引覆盖（复合索引）
对于select key_1 from t where key_2 ·····；这样的查询，查询的处理过程为：首先去检索key_2索引找到主键id，然后根据主键id去检索正确的数据行。这样就是两次检索。
将key_1和key_2加到联合索引，InnoDB可以直接在索引中获取结果数据集，这就是索引覆盖。
以下情况，InnoDB无法覆盖查询：
1 select选择的字段中含有不在索引中的字段 ，也即索引没有覆盖全部的列。
2 where 条件中不能含有对索引进行like的操作。
Join的列索引化
如果应用程序有很多 JOIN 查询，你应该确认两个表中Join的字段是被建过索引的。这样，MySQL内部会启动为你优化Join的SQL语句的机制。Join的字段，应该是相同的类型的，对于STRING类型，还需要有相同的字符集才行。（两个表的字符集有可能不一样）
