索引： http://www.cnblogs.com/linhaifeng/articles/7356064.html http://www.cnblogs.com/linhaifeng/articles/7274563.html
1.为什么要索引： sql 读写：10：1 读操作会出现性能问题； 优化查询是 重中之重； 索引： 为优化查询得提供得一种数据结构；键； primary key unique key都是索引 # foreign key 不是； primary key : 主键； unique key : 唯一 索引； index key： 普通索引 索引： 相当于书得目录； 缩小范围，减少查询次数 ，从而提升查询效率； io次数越少，查询效率越高； 索引就是尽可能多的减少io次数； http://www.cnblogs.com/linhaifeng/articles/7274563.html 索引： 读快 写会慢得 每新增一条数据 索引都会变化 不要盲目加索引，加多了 写会变慢得 2.Innodb存储引擎 索引分为：聚集索引，辅助索引； 主键： Innodb 为什么必须要有主键， Innodb 会自动建索引，先在表里找主键；若没有 不为空且唯一 默认设为主键 若没有，mysql会有隐藏得字段设为主键 以后可以基于主键 优化查询； 聚集索引： 叶子节点 存放得是 一整行得完整记录； 以后查询时，用id作为查询依据，可以加速查询； where id = 1; 用 where name=‘‘; 其他字段就不能提高查询效率； 辅助索引：就是对其他字段专门做索引。 和聚集索引区别； 聚集索引：叶子存放一整行记录 辅助索引：放字段 eg:name 值，主键得引用(id) select * from user where name = ‘alice‘ 先拿name 辅助索引，在拿id到聚集索引里面找 所有数据 加速查询： where 限定查询： select * from user . 遍历整张表 不能优化； select xxx from user where .... # 找到特定得某样 找多页内容，目录 微乎其微； 范围查询，索引用处比较小 id=... name=... 效率才高 条件明确 存储过程： 循环，300万次；不同得记录； 索引在数据量比较大得时候，效果比较好 测试索引；http://www.cnblogs.com/linhaifeng/articles/7274563.html#_label6 select * from user; # 慢 效率低 一条一条遍历； select count(id) from user where id = 1000; create index idx_id on user(id); # 建索引，慢 因为已经有数据了，把整个数据 都翻一遍 在做数据结构 索引； 插入数据也是比较慢得，因为要重新生成索引； select count(id) from user where id = 1000; 在查 就很快了 索引加速得好处了 如何正确使用索引； 联合索引； 覆盖索引；一般的应用系统，读写比例在10:1左右，而且插入操作和一般的更新操作很少出现性能问题，
在生产环境中，我们遇到最多的，也是最容易出问题的，还是一些复杂的查询操作，因此对查询语句的优化显然是重中之重。
说起加速查询，就不得不提到索引了。
索引在MySQL中也叫做“键”，是存储引擎用于快速找到记录的一种数据结构。索引对于良好的性能非常关键，尤其是当表中的数据量越来越大时，索引对于性能的影响愈发重要。索引优化应该是对查询性能优化最有效的手段了。索引能够轻易将查询性能提高好几个数量级。索引相当于字典的音序表，如果要查某个字，如果不使用音序表，则需要从几百页中逐页去查。
索引是应用程序设计和开发的一个重要方面。若索引太多，应用程序的性能可能会受到影响。而索引太少，对查询性能又会产生影响， 要找到一个平衡点，这对应用程序的性能至关重要。一些开发人员总是在事后才想起添加索引----我一直认为，这源于一种错误的开发模式。 如果知道数据的使用，从一开始就应该在需要处添加索引。开发人员往往对数据库的使用停留在应用的层面，比如编写SQL语句、存储过程之类， 他们甚至可能不知道索引的存在，或认为事后让相关DBA加上即可。DBA往往不够了解业务的数据流，而添加索引需要通过监控大量的SQL语句 进而从中找到问题，这个步骤所需的时间肯定是远大于初始添加索引所需的时间，并且可能会遗漏一部分的索引。当然索引也并不是越多越好， 我曾经遇到过这样一个问题：某台MySQL服务器iostat显示磁盘使用率一直处于100%，经过分析后发现是由于开发人员添加了太多的索引， 在删除一些不必要的索引之后，磁盘使用率马上下降为20%。可见索引的添加也是非常有技术含量的。索引的目的在于提高查询效率，与我们查阅图书所用的目录是一个道理：先定位到章，然后定位到该章下的一个小节，然后找到页数。
相似的例子还有：查字典，查火车车次，飞机航班等
本质都是：通过不断地缩小想要获取数据的范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件，
也就是说，有了这种索引机制，我们可以总是用同一种查找方式来锁定数据。
数据库也是一样，但显然要复杂的多，因为不仅面临着等值查询，还有范围查询(>、<、between、in)、模糊查询(like)、并集查询(or)等等。数据库应该选择怎么样的方式来应对所有的问题呢？我们回想字典的例子，能不能把数据分成段，然后分段查询呢？最简单的如果1000条数据，1到100分成第一段，101到200分成第二段，201到300分成第三段......这样查第250条数据，只要找第三段就可以了，一下子去除了90%的无效数据。但如果是1千万的记录呢，分成几段比较好？稍有算法基础的同学会想到搜索树，其平均复杂度是lgN，具有不错的查询性能。但这里我们忽略了一个关键的问题，复杂度模型是基于每次相同的操作成本来考虑的。而数据库实现比较复杂，一方面数据是保存在磁盘上的，另外一方面为了提高性能，每次又可以把部分数据读入内存来计算，因为我们知道访问磁盘的成本大概是访问内存的十万倍左右，所以简单的搜索树难以满足复杂的应用场景。
