索引-详解

B+tree：
页双向链接，数据都在叶子节点上
为什么B+,不是B?
1 双向链接：范围查询，扫表友好
2 B数叶子和非叶节点都含k-v，B+数非叶节点只含k，叶子节点含k-v，故B+数非叶节点能放更多数据，层高低，搜索快

B+数非叶节点能存放多少数据？页大小16k字节，一个主键+pointer大概14字节，能存放上千个

Cardinality: 我们一般高选择性数据建索引, show index from table_name 查看Cardinality
Cardinality表明不重复数据的预估值，Cardinality/记录数应尽量接近1
Cardinality 第一不实时更新，第二更新也是采样获取，不准确

细节：覆盖索引（走secondary后不走primary，secondary已经有查询的数据或者count查询走secondary更快）
不走索引(索引失效)：范围查询（走完secondary后还有很多数据，查询数据量很大，一般超过20%） 其他：不等于/复杂表达式/like ‘%abc’/优化器认为全表更快/联合索引最左边不好匹配
mrr (Multi-Range Read) 从secondary查出来的按主键索引排序，然后走主键索引查询（范围查询的优化方案，避免页反复被刷出，将随机访问变为更为顺序的访问）
icp（Index Condition Pushdown）在索引处进行where条件过滤，如(a,b)联合索引 where a=‘’ and b like ‘’; 联合索引就可以判断b like的条件，再走主键索引
force index() , use index()提示，不一定会走

hash：
缓冲池（lru_list）页面查找：（space_id, page_offset）比如非叶节点告诉我10<id<20的去page_offset为000008的页面去找，这张页面我要通过hash（space_id, page_offset）得到具体槽（链表解决冲突），槽有指向内存页面指针
自适应hash
hash索引：搜索快，但若碰撞严重也会慢，基本只能用于等值查询

全文检索： fulltext index match(column_name) against(‘value’)
倒排索引
inverted file index 单词—单词所在文档
full inverted index 单词word— ilist（单词所在文档，具体位置） Innodb使用这种形式,并在word上有索引