一，索引
1.Innodb索引使用的是B+树
2.尽量简化where条件，比如不要出现 where id + 3 = 5,这无法使用索引
3.索引很大时，可以冗余一列来模拟哈希索引
4.小的表不需要使用索引，很大的表需要用分块技术，也不用索引
5.索引的选择性=不重复的数量/总的数量
选择性越高，效率越高，unique索引选择性为1，效率最好
对于blob，text，很长的varchar类型的列，必须使用前缀索引。
诀窍在于，要选择足够长的前缀以保证较高的选择性，同时又不能太长
创建前缀索引：(city列里长度为7的前缀索引)
alter table sakila.city_demo ADD KEY(city(7))
前缀索引的缺点，无法做ORDER BY和GROUP BY
后缀索引：mysql不支持反向索引，但可以把字符串反转后存储，并基于此建立索引，可以通过触发器来维护索引
6、多列索引
对多个列做相交操作（and）时，需要的时一个多列索引而不是多个单独的单列索引
如果在explain中看到有索引合并，应该好好检查一下查询和表单结构，
可以通过参数optimizer_switch来关闭索引合并
7.覆盖索引
如果一个索引包含所有需要查询的字段的值，我们就称之为覆盖索引
由于myISAM在内存中只存索引，所以用覆盖索引有严重的性能问题
由于InnoDB的聚簇索引，覆盖索引对InnoDB特别有用
另外，只能用B-tree索引做全文索引
当使用覆盖索引时，EXPLAIN 中的Extra中显示Using index
查询优化
一般的优化方法有两个
1.确认应用程序是否在检索大量超过需要的数据，这通常意味着访问了太多的行
但有时候也可能是访问了太多的列
2.确认MySQL服务器层是否在分析大量超过需要的数据行
解决方法，加limit，
如果数据库资源紧张，可以考虑用mybatis代替hibernate
取出全部列，会让优化器无法完成覆盖索引扫描这类优化，比如hibernate
不过获取所有列的查询缓存，比多个独立的只获取部分列的查询缓存更有好处
每次看到select * 请去怀疑一下是否真的需要全部取出
重复查询相同的数据：请把这个数据缓存起来，比如放到session中
最简单的衡量查询开销的三个指标：
响应时间，
扫描的行数
返回的行数
这三个指标都会记录到mysql的慢日志中，所以检查慢日志
如果发现查询需要扫描大量的数据行，但返回少量的行，那么可以尝试下面的技巧去优化它
1，使用索引覆盖扫描，把所有需要用的列都放到索引中
2.改变表结构，例如使用单独的汇总表
3.重写这个查询，各种优化
有时可以考虑将一个复杂查询分为多个小查询，如果能减少工作量的话
比如删除旧的数据，每次删一点，可以避免一次锁住很多数据
分解关联查询的好处
1、缓存效率更高
2、用返回的数据的id来进行顺序查询比用join进行随机关联效率更高
坏处：一条语句分多条，增加连接开销
排序优化
无论如何，排序都是一个成本很高的操作，所以从性能角度考虑，尽可能避免排序，或避免对大量数据进行排序