1.数据库索引：是增加或者删除多余的索引，尽量使用联合索引。同时注意null值对索引的影响
2.像有时数据库数据量大，sql语句in外面与in里面数据量都大的时候，如几十万的时候。把两个集合查询出来在实现层比较。一个用数组ArrayList接收，遍历快。一个用HashSet接收，一次命中，时间复杂度O(1)。
3.如果是分页列表，要注意当数据量大时，如果该分页排序规则复杂，就算是前面100页翻页可能都会慢，更别说尾页了。思路：先查当前页的id集合， 在根据这些id去找对应的数据.。如下，先查2里面第一页所有id，等等。。。
4.使用多线程
5.不用Select * ，就不用多说了
6.mysql 的优化表命令：optimize table，navicat就：左键点击某个表—>维护----> 优化表。
为什么要优化表，因为可变字段经常修改，会产生多余的空白段及碎片，如果使用delete语句删除记录，其实物理上也没有真的删除这条记录。你会发现删除后该数据文件的大小没变，MySQL为啥这样设计，就是当新增的时候新增记录回去填补那些被标记为删除的空间，因为新增记录并不会百分百填补碗删除记录的空间，也会产生空白段与碎片。所以当觉得某个表经过以上几种方法后还是查询慢，就可使用这个。同时可使用 show table status来查看哪张表空白空间比较多。
7.案例：在几百万数据里取出某个粉丝最新的消息。（主键id自增）
一般写法：select create_time createTime from wx_msg where wx_user_id=#{userId} order by create_time desc limit 1
优化写法：select create_time createTime from wx_msg where wx_user_id=#{userId} order by id desc limit 1
原因：因为主键id自增，所以order by create_time与order by id desc效果一样，但order by id更快，排序时直接走的主键索引，没有回表
8.案例in（）里面的子查询用到聚合函数时会导致in不走索引
解决办法：再包一层
一般写法：select * from dev_mc where id in(SELECT min(id) from dev_mc where id>757575)
优化写法：select * from dev_mc where id in(select * from (SELECT min(id) from dev_mc where id>757575)a)
