深入浅出分析MySQL MyISAM与INNODB索引原理、优缺点分析
本文浅显的分析了MySQL索引的原理及针对主程面试的一些问题，对各种资料进行了分析总结，分享给大家，希望祝大家早上走上属于自己的"成金之路"。
学习知识最好的方式是带着问题去研究所获取的资料，分析所获取资料的优点和不足，然后归纳汇总资料，结合使用场景形成整体的知识脉络体系，本文行文依据各类问题展开，并附上具体的资料，引导大家走上属于自己的"成金之路"。
目录：
1.索引有哪几种？各种索引优缺点？
2.索引的结构及为什么使用这种结构？
3.INNODB表索引常见面试问题——"最左缀"及ID自增问题
1.索引有哪几种？各种索引优缺点？
提及索引，第一个问题应该是索引有哪几种，各种索引有啥优缺点，针对这个问题去搜索资料，较全面及优质的资料见http://www.2cto.com/database/201501/368126.html；这里做一个简单汇总：
-
按表类型分为：MyISAM表索引与INNODB表索引；按索引特征又分为唯一索引与全文索引、单列索引与多列索引、聚簇索引。
-
MyISAM表索引与INNODB表索引区别：
- 聚簇索引指索引中键值与表数据存储在一起，这里主要是INNODB表索引，显然索引与数据存在一起的好处就是数据获取效率高。
- 而MyISAM表索引与表数据是分开存储的，索引保存在"表名.MYI"文件内，而数据保存在"表名.MYD"文件内；
- 其它注意点
- 另外一个重要的区别是MyISAM表不支持事务，INNODB表在每行数据中增加了DB_TRX_ID、db_roll_ptr、db_row_id三个值来支持事务。
- 唯一索引强调索引值必须唯一，比如主键；全文索引一般在CHAR、VARCHAR或TEXT列上创建，MyISAM表支持而INNODB表不支持，常见主要针对文本进行索引。
- 典型的应用场景区分：MyISAM表索引在处理文本索引时更具优势，而INNODB表索引在其它类型上更具效率优势，同时MySQL高并发需要事务场景时，只能使用INNODB表。
2.索引的结构及为什么使用这种结构？
- 索引的结构大家都都知道是B+Tree，那么第一个问题就是为什么要使用这种Tree，而不是RB-Tree?
这点从磁盘读写上给出解释，磁盘顺序读写时才能达到其宣传的数值(fio可以进行简单的读写测试)，因为随机读写，机械磁盘需要旋转及寻道时间，哪怕是ssd，随机读写也需要寻址时间；那么如果将索引tree构建的层数越低，使得key相近的数据都存在一起，伴随磁盘预读特性，能更进一步提高性能。
那么使用B+Tree的关键就是Tree层数低(3层)，有序的数据存储位置接近，结合磁盘顺序读写、OS预读写特性，使得能很快定位到数据；而使用RB-Tree时key值相近的数据会存储的较远，导致效率低下。
- 另外的一个问题就是数据插入时，怎么来平衡树，详见http://taop.marchtea.com/03.02.html。
- 同时就是为了提高存储效率，尽量较少进行Tree的平衡操作，通过让key尽量保持自增，这样新增的数据即可按顺序进行存储，而不会或少量对已经存储的数据进行变更。
3.INNODB表索引"最左缀"及ID自增问题
- "最左缀"问题即创建联合索引(a,b,c)的使用问题？
- 首先要明白多列索引与联合索引区别
参见http://www.infocool.net/kb/Mysql/201603/26364.html以文件字节进行了分析。
- 多个单列索引一个索引一棵树：
MyISAM联合索引时，因为Tree存储的是地址，故每个索引都能追踪到表数据地址；
InnoDB表数据和索引一起构成B+Tree，这里假设a为Primary Key，InnoDB表数据与按Primary Key构成B+Tree，然后创建b(second-key)、c(third-key)时，根据的b、c两列的数据作为key构建索引，而索引中存储的数据为Primary-Key值，查询时先检查辅助索引获得Primary-Key，然后再根据Primary-Key获取数据
故InnoDB主键建议为单调，且不宜过长。
- 多列组成联合索引一棵树：
假设a为主键，则以a先放，a相同的情况下按b的顺序放，然后b相同按照c的顺序放。
那么"最左缀"问题就很容易解释清楚了，像(b,c)/(c)/(a,c)，因为无法按照索引树的规则来进行索引，导致需要全局扫描；而(a)/(a,b)/(a,b,c)则能使用到索引。
另外针对(a,c)如果b列的数据都是重复数据，比如星期数据，则可以将(a,c)转为(a,b in (monday, ..., sunday),c)进行索引。
查询优化问题详见http://blog.codinglabs.org/articles/theory-of-mysql-index.html优化部分。
ID自增问题
显然INNODB表索引需要ID自增效率更好，而为了保证高并发下安全，采取锁表，进行ID的自增，详见http://www.cnblogs.com/zhoujinyi/p/3433823.html;另外锁表效率在超高并发下，肯定效率会受到影响，那么引入"预申请"机制来提高效率，即为每次不定的操作多申请几个ID，保证效率，但会导致不连续。
希望祝大家早上走上属于自己的"成金之路"，如果觉得不错，烦请不吝"推荐"，助于传播。谢谢，转载请注明出处(百度搜 成金之路)。
也可将我没有涉及到的问题进行留言，然后我去搜集资料、整理更新。
