最左匹配原则
free链表
每页16k，操作系统每页默认时4k或者8k
普通索引辅助索引二级索引
id数据
存储引擎是在磁盘中的：存储数据的，分两种，一个时innodb，一个时myisamserver是一个进程
页
控制块
当使用其他索引的时候，叶子节点中并不包括整行的数据值，需要取主键索引中进行数据查找的过程叫做回表回表表示，回到数据所在的那颗B+树进行查询操作select * from t where name = zhangsan
基节点1 多少空余节点2 头节点3 尾节点
server
主键索引
buffer pool
flush链表
组合索引联合索引
优化器
面试官问我，为什么主键一般是选择自动递增的？涉及到索引的维护，元素值的添加和删除都会影响整个树的结构或者层数如果选择自动的，之前的结构都是固定的，顶多是后面追加，改动很小；而如果不是自增的比如是随机的，那么要在原来已经生成的树结构进行页分裂，然后插入整个新值，可能当前页的上级节点还要发生页分裂，上上节点也会影响，页分裂很浪费性能；
控制块
CBORBO
创建索引时，选择int类型还是varchar类型？谁占用的空间小就用谁
回表
存储引擎（持久化工具）文件myisam innodb
索引分类
查询缓存，命中率太低，mysql8版本之后失效
索引
B+树一般是3-4层，就能支持千万级别的数据量
部分写入成功：结合RedoLog获取最新数据；如果写入成功，删除RedoLog
进程
一定要先从左边查
IO
连接器
热数据
词法分析语法分析
RedoLog
覆盖索引
原来在server中做的数据过滤操作下推到存储引擎层中来完成
正常每个磁盘块是16k，每个磁盘块数据范围是，16 / (key + 地址)，结果就是 degree（阶、度）的大小
减少io量
淘汰策略：当buffer pool节点满了，下次查询后，放入新的页后，发现已经满了，肯定要触发淘汰机制的
跟存储引擎交互
控制块
冷数据
全文索引
es
nameid
更新后，那个页就是脏页，后面会有专门的进程把脏页更新到磁盘中
分析器
执行器
磁盘
之前创建的索引都是一个列，当一个索引包含一个或多个列的时候，可以称之为组合索引
提供访问效率
唯一索引
lucene
select * from table where name = ? and age = ?mysql 5.7才有的一个特征：没有索引下推之前：现根据name的值到存储引擎中把数据取过来，然后到server中根据age进行过滤有索引下推之后：根绝name 和 age两个列的值到存储引擎中做数据筛选，不需要再到server中进行过滤了
部分写入成功：也没事，反正双写缓冲区已经都有了；如果写入成功，什么事都没有了
Innodb Page 16kb
减少io次数
double write buffer
LRU链表
solr
索引面试必问
不同数据文件的组织形式
索引下推
链表：存储buffer pool中空余节点的位置
缓存：内存 128M
八分之五是热数据，八分之三是冷数据；数据页第一次放入控制块后，就先放入冷数据块，并记下此时时间t1，当下次查询用到这个控制块时，记下第二次时间t2，t2 - t2 > 1s，才会插入热数据快的头部
1.先写入双写缓冲区
2.写入表空间
B+树的索引结构：只有最下面的叶子节点才存放data数据，其他的节点只是存放指针和索引字段的key（比如主键id是索引，key就是id对应的值）B树，每个磁盘块，不光有指向其他叶子节点的指针、key，还有data，所以B树每个磁盘块的数据范围变小了
