数据库索引

为什么要用索引?
当数据量较大时，避免将全表加载到内存，进行全表的扫描，加快查找的速度和节约内存。这跟查字典的原理是一样的，目录就是索引，假如你查一个汉字，肯定不会一页一页的查询后面的正文吧。。。
B树

B Tree的规则：
一、根节点至少两个孩子
二、每个节点至多m个孩子（m是树的高度）
三、除了根节点和叶子节点外，其他节点至少有ceil(m / 2)个孩子
四、所有的叶子节点在同一层
五、关键字升序
六、关键字比指针域少一
七、第一个指针域指向的关键字小于第一个关键字，最后一个指针域指向的关键字大于最后一个关键字，其他介于之间。
B+ trees索引

B+ Tree规则：
一、指针域数量等于关键字数量
二、非叶子节点只用来索引，不存数据，数据都存在叶子节点中（主键id,指向文件系统的指针）
三、叶子节点之间存在相连的指针
四、指针域pi指向的关键字位于[ki,ki+1)之间
为什么选择用B+树做索引
一、树比较矮，非叶子节点不存数据，只用来索引，大大减小磁盘I/o的次数，提高性能
二、叶子节点之间指针相连，支持范围查询
三、B+树查询稳定，都是从根节点到叶子节点。
hash索引的缺点
一、不支持范围查询
二、存储的是hash值，Hash值的排序不能代表原有值的排序
三、不支持部分索引键查询，因为联合索引存的是他们一起之后的hash值，跟将各个索引分别hash之后的值，没有关系，并不是简单的相加。
四、不能避免表扫描
详解
主键索引

辅助索引

    create clustered index clustered_index on t1(a)
    --创建主键，表的数据就按照上面B+树的结构存储在磁盘上，如果没有主键， 会按照第一个非空字段数据创建，如果没有，会有一个隐藏row_id来创建B+树。
 这就是聚集索引，叶子节点下面装的就是数据页。创建索引的目的就是排序表中的数据
 CREATE indx_bcd ON t1(b,c,d);
 --辅助索引，会构建出另外一颗B+树，来辅助查找，是按照b,c,d字段组合的大小排序，创建字段的时候会指定字符集，后面会跟有比较的规则。
 select * from t1 where a = 1;
 --走主键索引，来查找。
 select * from t1 where b = 1 and c = 1 and d = 1;
 --先走辅助索引找到主键值，再到主键索引中去查找，找到数据页（回表）。
最左匹配原则：最左优先，以最左边的为起点任何连续的索引都能匹配上。同时遇到范围查询(>、<、between、like)就会停止匹配。 
select * from t1 where b like '%12';
--走全表扫描
select * from t1 where b = 1;
--走辅助索引，回表找到数据页
select * from t1 where b > 1;
--走全表扫表，理论上是可以先走辅助索引找b = 1，然后右边的都是b > 1,但是回表的代价高，查询优化器会判断，走全表扫描。
select * from t1 where b = 1 and c = 1 and d = 1 and a > 1;
--会发现key_len = 15，证明用的是前面的联合索引，不能同时用两个索引。
select * from t1 where b = 1 and c = 1 and d = 1 or a > 1;
--会发现key_len = 19,用的是两个索引（组合索引），原因是在辅助索引比较大小的时候建立B+树时，当辅助索引的数据相等时，不能比较大小，sql会做优化将主键索引放到一起，见下图的组合索引
 select * from t1 where b = 1 and b like '%1%';
 --只能走b  = 1索引，先走辅助索引，回表（Innodb引擎），到service做 b like '%1%'
 可以优化，先走辅助索引，做 b like '%1%'，回表，找到数据页，这叫做索引条件下推（push）
select b from t1;
--理论上有两种走法，全表扫描，或者覆盖索引（辅助索引里面的索引中含有要查询的数据），查询优化器，会选择走覆盖索引，因为辅助索引的叶子节点下面装的主键值，一页可以装很多索引，查询较快。

组合索引

加了索引还是慢，该怎么办?
查看索引的选择性，优化索引
多表联合查询提高JOIN BUFFER空间大小

select * from t1 join t2 on t1.a = t2.a;查询优化器会优化，都是小表驱动大表完成查询，
例如t1是小表，t2是大表，先在t1表里面找a,然后将查询结果放到JOIN BUFFER，再到t2表中去查询

分库分布
读写分类
加缓存