1、如果在(a,b,c)三个字段上建立联合索引，那么它能够加快 a | (a,b) | (a,b,c) 三组查询速度。
select count(distinct left(code, 5))/count(*) from device;
说明：建索引时使用上述语句看看区分度，选择合适的长度，通常区分度达到80%左右就可以建索引了。
2、建联合索引的时候，区分度最高的字段在最左边。
3、如果建立了(a,b)联合索引，就不必再单独建立 a 索引。同理，如果建立了(a,b,c)联合索引，就不必再单独建立 a、(a,b) 索引。
4、存在非等号和等号混合判断条件时，在建索引时，请把等号条件的列前置。如where a>? and b=?，那么即使 a 的区分度更高，也必须把 b 放在索引的最前列。
5、最左侧查询需求，并不是指 SQL 语句的 where 顺序要和联合索引一致，但建议保持一致。
6、范围条件有：<、<=、>、>=、between等。范围列可以用到索引（联合索引必须是最左前缀），但是范围列后面的列无法用到索引，索引最多用于一个范围列，如果查询条件中有两个范围列则无法全用到索引。
7、在字段上进行计算不能命中索引，应把计算放到业务层。如：select * fromdoc where YEAR(create_time) <= '2016'。
8、强制类型转换会全表扫描。
9、更新十分频繁、数据区分度不高的字段上不宜建立索引。更新会变更 B+ 树，更新频繁的字段建立索引会大大降低数据库性能。“性别”这种区分度不大的属性，建立索引是没有什么意义的，不能有效过滤数据，性能与全表扫描类似。
10、order by 最后的字段是组合索引的一部分，并且放在索引组合顺序的最后，避免出现 file_sort 的情况，影响查询性能。例如对于语句 where a=? and b=? order by c，可以建立联合索引(a,b,c)。
11、如果索引中有范围查找，那么索引有序性无法利用，如 WHERE a>10 ORDER BY b;，索引(a,b)无法排序。
12、MySQL 并不是跳过 offset 行，而是取 offset+N 行，然后返回放弃前 offset 行，返回 N 行，那当 offset 特别大的时候，效率就非常的低下，要么控制返回的总页数，要么对超过特定阈值的页数进行 SQL 改写。selecta.* from 表1 a,(select id from 表1 where 条件 limit100000,20 ) b where a.id=b.id
13、SQL 性能优化 explain 中的 type：至少要达到 range 级别，要求是 ref 级别，如果可以是 consts 最好。consts：单表中最多只有一个匹配行（主键或者唯一索引），在优化阶段即可读取到数据。ref：使用普通的索引（Normal Index）。range：对索引进行范围检索。当 type=index 时，索引物理文件全扫，速度非常慢。
14、单表索引建议控制在5个以内。单索引字段数不允许超过5个。字段超过5个时，实际已经起不到有效过滤数据的作用了。
15、错误观点：索引越多越好，认为一个查询就需要建一个索引。宁缺勿滥，认为索引会消耗空间、严重拖慢更新和新增速度。抵制惟一索引，认为业务的惟一性一律需要在应用层通过“先查后插”方式解决。过早优化，在不了解系统的情况下就开始优化。
16、使用如下方式来避免 sum 的 NPE 问题：SELECT IF(ISNULL(SUM(g)),0,SUM(g)) FROM table。