索引：键与索引
主键
为什么用自增列作为主键
如果我们定义了主键(PRIMARY KEY)，那么InnoDB会选择主键作为聚集索引。
如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引。
如果也没有这样的唯一索引，则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增，
这个ROWID不像ORACLE的ROWID那样可引用，是隐含的)。
数据记录本身被存于主索引（一颗B+Tree）的叶子节点上，
这就要求同一个叶子节点内（大小为一个内存页或磁盘页）的各条数据记录按主键顺序存放
因此每当有一条新的记录插入时，MySQL会根据其主键将其插入适当的节点和位置，
如果页面达到装载因子（InnoDB默认为15/16），则开辟一个新的页（节点）
如果表使用自增主键，那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，
当一页写满，就会自动开辟一个新的页
如果使用非自增主键（如果身份证号或学号等），由于每次插入主键的值近似于随机，
因此每次新纪录都要被插到现有索引页得中间某个位置
此时MySQL不得不为了将新记录插到合适位置而移动数据，甚至目标页面可能已经被回写到磁盘上而从缓存中清掉，
此时又要从磁盘上读回来，这增加了很多开销
同时频繁的移动、分页操作造成了大量的碎片，得到了不够紧凑的索引结构，
后续不得不通过OPTIMIZE TABLE来重建表并优化填充页面。
key和index的区别
key 是数据库的物理结构，它包含两层意义和作用，
一是约束（偏重于约束和规范数据库的结构完整性），
二是索引（辅助查询用的）。包括primary key, unique key, foreign key 等
index是数据库的物理结构，它只是辅助查询的，
它创建时会在另外的表空间（mysql中的innodb表空间）以一个类似目录的结构存储。
索引要分类的话，分为前缀索引、全文本索引等；
索引
为什么使用数据索引能提高效率
数据索引的存储是有序的
在有序的情况下，通过索引查询一个数据是无需遍历索引记录的
极端情况下，数据索引的查询效率为二分法查询效率，趋近于 log2(N)
B+树索引和哈希索引的区别
B+树是一个平衡的多叉树，从根节点到每个叶子节点的高度差值不超过1，
而且同层级的节点间有指针相互链接，是有序的
哈希索引就是采用一定的哈希算法，把键值换算成新的哈希值，
检索时不需要类似B+树那样从根节点到叶子节点逐级查找，
只需一次哈希算法即可,是无序的
哈希索引的优势：
等值查询，哈希索引具有绝对优势（前提是：没有大量重复键值，如果大量重复键值时，哈希索引的效率很低，
因为存在所谓的哈希碰撞问题
哈希索引不适用的场景
- 不支持范围查询
- 不支持索引完成排序
- 不支持联合索引的最左前缀匹配规则
通常，B+树索引结构适用于绝大多数场景，像下面这种场景用哈希索引才更有优势：
在HEAP表中，如果存储的数据重复度很低（也就是说基数很大），对该列数据以等值查询为主，没有范围查询、
没有排序的时候，特别适合采用哈希索引，
例如这种SQL：
# 仅等值查询
select id, name from table where name='李明';
select id, name from table where name='李明';
而常用的 InnoDB 引擎中默认使用的是B+树索引，它会实时监控表上索引的使用情况。
如果认为建立哈希索引可以提高查询效率，则自动在内存中的“自适应哈希索引缓冲区”建立哈希索引（在InnoDB中默认开启自适应哈希索引）。
通过观察搜索模式，MySQL会利用index key的前缀建立哈希索引，如果一个表几乎大部分都在缓冲池中，那么建立一个哈希索引能够加快等值查询。
注意：在某些工作负载下，通过哈希索引查找带来的性能提升远大于额外的监控索引搜索情况和保持这个哈希表结构所带来的开销。
但某些时候，在负载高的情况下，自适应哈希索引中添加的read/write锁也会带来竞争，比如高并发的join操作。
like操作和%的通配符操作也不适用于自适应哈希索引，可能要关闭自适应哈希索引。
MySQL联合索引
1、联合索引是两个或更多个列上的索引。
对于联合索引:Mysql从左到右的使用索引中的字段，一个查询可以只使用索引中的一部份，但只能是最左侧部分。
例如索引是key index (a,b,c). 可以支持a 、 a,b 、 a,b,c 3种组合进行查找，但不支持 b,c进行查找 .
当最左侧字段是常量引用时，索引就十分有效。
2、利用索引中的附加列，您可以缩小搜索的范围，但使用一个具有两列的索引不同于使用两个单独的索引。
复合索引的结构与电话簿类似，人名由姓和名构成，电话簿首先按姓氏对进行排序，然后按名字对有相同姓氏的人进行排序。
如果您知道姓，电话簿将非常有用；如果您知道姓和名，电话簿则更为有用，但如果您只知道名不知道姓，电话簿将没有用处。
什么情况下应不建或少建索引
- 表记录太少
- 经常插入、删除、修改的表
- 数据重复且分布平均的表字段，假如一个表有10万行记录，有一个字段A只有T和F两种值，
且每个值的分布概率大约为50%，那么对这种表A字段建索引一般不会提高数据库的查询速度。
4、经常和主字段一块查询但主字段索引值比较多的表字段。
MySQL索引使用的数据结构主要有BTree索引 和 哈希索引
对于哈希索引来说，底层的数据结构就是哈希表，因此在绝大多数需求为单条记录查询的时候，
可以选择哈希索引，查询性能最快；其余大部分场景，建议选择BTree索引。
MySQL的BTree索引使用的是B树中的B+Tree，但对于主要的两种存储引擎的实现方式是不同的。
MyISAM: B+Tree叶节点的data域存放的是数据记录的地址。
在索引检索的时候，首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其 data 域的值，
然后以 data 域的值为地址读取相应的数据记录。这被称为“非聚簇索引”。
InnoDB: 其数据文件本身就是索引文件。
相比MyISAM，索引文件和数据文件是分离的，其表数据文件本身就是按B+Tree组织的一个索引结构，
树的叶节点data域保存了完整的数据记录。
这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。
这被称为“聚簇索引（或聚集索引）”。
而其余的索引都作为辅助索引，辅助索引的data域存储相应记录主键的值而不是地址，这也是和MyISAM不同的地方。
在根据主索引搜索时，直接找到key所在的节点即可取出数据；
在根据辅助索引查找时，则需要先取出主键的值，再走一遍主索引。
因此，在设计表的时候，不建议使用过长的字段作为主键，也不建议使用非单调的字段作为主键，这样会造成主索引频繁分裂
B树
B树和B+树的区别
B树，每个节点都存储key和data，所有节点组成这棵树，
并且叶子节点指针为nul，叶子结点不包含任何关键字信息。
B+树，所有的叶子结点中包含了全部关键字的信息，
及指向含有这些关键字记录的指针，且叶子结点本身依关键字的大小自小而大的顺序链接
所有的非终端结点可以看成是索引部分，结点中仅含有其子树根结点中最大（或最小）关键字。
(而B 树的非终节点也包含需要查找的有效信息)
为什么说B+比B树更适合实际应用中操作系统的文件索引和数据库索引？
1、B+的磁盘读写代价更低。
B+的内部结点并没有指向关键字具体信息的指针，因此其内部结点相对B树更小。
如果把所有同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。
一次性读入内存中的需要查找的关键字也就越多。
相对来说IO读写次数也就降低了。
2、B+-tree的查询效率更加稳定。
由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。
所以任何关键字的查找必须走一条从根结点到叶子结点的路。
所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。
