002--mysql索引

在mysql中，索引是在存储引擎层而不是在服务器层实现的。所以，并没有统一的索引标准。mysql实现了插件式的存储引擎。存储引擎存储的是表。

如果没有特别指明，当人们谈论mysql索引的时候，多半是说b-tree索引。b-tree是一种多路查找树。大多数Mysql引擎都支持这种索引。

我们用的最多的innodb引擎用的是b+tree。其实就是b-tree的一个变种。最大的区别是所有的节点数据都存储在叶子节点，其他节点只是存储值跟指向叶子节点的指针，而且叶子节点用指针连起来（天然排序）。这种结构，对于那种查找范围的sql来说，再适合不过。

在用联合索引时，要注意到最左匹配的情况。

值得注意的是，查询中的order by操作也可以用上b-tree索引。

还有一类索引叫哈希索引，innodb不支持这种索引。原理就是哈希表，不用多说。

全文索引：他查找的是文本中的关键词，而不是直接比较索引列中的值。这个跟lucene等全文搜索引擎很像。

索引是最好的解决方案吗？对于非常小的表，大部分情况下简单的全表扫描更高效。对于中到大型的表，索引就非常有效。但是对于特大型的表，建立和使用索引的代价将随之增长。这种情况下，则需要一种技术可以直接分出查询需要的一组技术，而不是一条一条记录地匹配。例如分区技术。

下面介绍几个使用索引的注意点
1，索引要是独立的列才能使用。比如 sum(username) , age +1 = 34等，索引变成了表达式的一部分，就不能使用索引。
2，如果索引列过长，比如text类型，就不能全部索引，否则维护成本将会变得巨大。可以用前缀索引，就是说从前面截取部分字符来建立索引。
3，对于联合索引，要注意最左匹配的问题。还有就是谁先谁后的问题，经验上来说，命中率高的排在前面。

聚簇索引：并不是一种单独的索引类型，而是一种数据存储方式。具体的细节依赖其实现方式，但是innodb的聚簇索引实际上在同一个结构中保存了b-tree索引和数据行。聚簇索引就是物理数据的顺序跟索引的顺序一样。
当表有聚簇索引时，他的数据实际上存放在树的叶子中。根据聚簇索引的特点，一个表只能有一个聚簇索引。

innodb只允许主键列做聚簇索引。如果没有定义主键，innodb会选择一个唯一的非空索引代替。如果没有这样的索引（比我我们没有建索引），innodb会隐式定义一个主键来作为聚簇索引。

聚簇索引的优点，因为数据被索引物理的“聚”到了一块，所以磁盘在获取数据时是顺序io的，只需要扫描硬盘的一小块就可以拿到符合条件的全部数据。缺点是在有新数据插入时，维护成本也更高。

覆盖索引：覆盖索引不是一种新的索引类型，而是指其符合某一类查询优化，称其为这一类查询的覆盖索引。我们知道，索引里面存的是物理数据的地址，但是如果索引中存在的数据就符合我们的查询需求，那我们还有什么必要再去真实数据里面找呢？这样节省了大量的磁盘io，举个栗子，有个联合所以user,age
查询语句为 select age from xx where user = ‘jim’
查询所有叫jim的人的年龄，user跟age都在索引中存着呢，就没有必要再去io物理数据了。

在真实的开发环境中，有意的去根据某一类或者几类查询去建立覆盖索引，将是一个很不错的选择。对提升程序的效率，显而易见。