一些网上找到的经验之谈。
建立索引的几大原则
最左前缀匹配
最重要的大原则
具体可见mysql索引使用策略和优化
mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。
tips
- 尽量选择区分度高的列作为索引，区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少
- 索引列不能参与计算，保持列“干净”，比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引
- 尽量的扩展索引，不要新建索引。
- 对于定义为text、image和bit的数据类型的列不要建立索引。
- 对于经常存取的列避免建立索引
索引使用的注意点——为什么我的索引没有使用
一般说来，索引应建立在那些将用于JOIN,WHERE判断和ORDER BY排序的字段上。尽量不要对数据库中某个含有大量重复的值的字段建立索引，例如对于一个ENUM类型的字段来说，出现大量重复值是很有可能的情况。
应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描；最好不要给数据库留NULL，尽可能的使用 NOT NULL填充数据库.
应尽量避免在 where 子句中使用 != 或 <> 操作符，否则将引擎放弃使用索引而进行全表扫描。
应尽量避免在 where 子句中使用 or 来连接条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描。
in 和 not in 也要慎用，否则会导致全表扫描。
1
select id from t where num in(1,2,3)
对于连续的数值，能用 between 就不要用 in 了：
1
select id from t where num between 1 and 3
很多时候用 exists 代替 in 是一个好的选择，例如
1
select num from a where num in(select num from b)
可以用下面的语句替换：
1
select num from a where exists(select 1 from b where num=a.num)
下面的模糊查询也将导致全表扫描：
1
select id from t where name like '%abc%'
一般情况下不鼓励使用like操作，如果非使用不可，如何使用也是一个问题。like “%aaa%” 不会使用索引，而like “aaa%”可以使用索引。
若要提高效率，可以考虑全文检索。
既然谈到模糊查询下使用索引，我们就顺便详细地讲讲吧。
like %keyword索引失效，使用全表扫描。但可以通过翻转函数+like前模糊查询+建立翻转函数索引=走翻转函数索引，不走全表扫描。例子like keyword%索引有效。like %keyword%索引失效，也无法使用反向索引。
1
2
3
4//可以拿我给出的数据库试一下嘛。然后用explain测试，就能测出有没有走索引了
select * from table where code like '王%'
select * from table where code like '%王%'
select * from table where code like '%王'如果在 where 子句中使用参数，也会导致全表扫描。
应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描
不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。
应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源
MySQL查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。