mysql索引
聚簇索引，索引分类，技术名词（回表，索引覆盖，最左匹配，索引下推），执行计划
索引是干嘛的：字典，快速定位数据
索引是否是一个文件？索引是否需要持久化存储？（是，是）
存在磁盘需要存什么样的信息
索引里存储什么东西：1，键，key值。2，当前记录位于哪一个文件。3，当前记录偏移量 key,file_name,offsets这样的结构可以
大数据技术hive存储的索引为——key,file_name,offsets
大数据为OLAP
OLAP——联机分析处理——对历史数据的分析，产生决策影响
数据库为OLTP
OLTP——联机事务处理——必须要在很短的时间内反馈结果
mysql用的是B+树，不用hive方式因为扫描太慢
B+树——树——数据结构
现有数据结构：哈希表，二叉树，红黑树，AVL（二叉平衡树），B树
哈希表：空间，数组，key值一样累加数据，有下标编号，插数据先计算哈希值，查询也是先计算哈希值，存在的毛病为冲突，数据散列不均匀，导致存储空间浪费
1，哈希冲突问题，设计优秀的hash算法，保证数据能尽可能多的散列。
2，需要占用很多的内存空间，此时比较耗费内存。
3，适合等值查询，但是不适合范围查询，生产环境范围查询多
mysql是否有hash索引？有，存储引擎，memory使用hash索引，还有innodb这种存储引擎支持自适应hash
show engine
一个树里有且仅有两个节点为二叉树，BST树，二叉排序树，二叉搜索树
数组的时间复杂度，数组排序可以进行二分查找，左子树小于根节点，右子树大于根节点，在数据插入的时候就进行排序，若是一个递增或一个递减插入，就变成了链表，又是O(N)复杂度
让树尽可能保持平衡，AVL二叉平衡树，每次进行旋转操作，在进行数据节点插入的时候尽可能保持平衡，最高子树和最矮子树高度不能超过1，AVL树损失一部分插入的性能来满足查询性能的提升
有可能查询和插入性能一半一半，就有问题，AVL树过渡到红黑树
红黑树也是一棵二叉平衡树，最长子树不超过最短子树的两倍即可，非严格二叉平衡树，这时候插入性能和查询性能尽可能平衡
为什么索引不用这三种数据结构？最大的问题在于每个节点只存储一个值，只能不断加深树的深度，IO量，只能从硬件层面改。1，尽量减少IO次数。2，尽量减少IO量。
操作系统知识：1，局部性原理：经常被查询的数据有聚集成群的倾向，同时刚被查询的数据有可能很快会被再次查询。2，磁盘预读：磁盘跟内存进行交互的最小逻辑单位，一般都是跟操作系统相关，是4K或者8K，可以称为datapage，或者叫页。
能不能让每一个数据节点里多存储些数据。各种树深度太深的原因为二叉树，如果变成多叉树，并且每个节点多存储数据，变为B树。
阶，degree=3,4，就是每个节点可以最多存多少数据
控制每一个节点里都是4K，格子里不止可以放一个key值
每次读取的时候可以是4K也可以是8K，一般为4K的倍数。innodb引擎读取的是16K。
p1,p2,p3为指针，16，34为存储的key值，data为数据记录。
三次 48K，找到28
一般一行记录1K，磁盘块1最多放16条记录。16的3次方，4096条记录。不合适，树深变深的话IO多。
data干掉不存储数据了。
B+树。有些key的值是重复的。每一个磁盘块还是16K。第一个磁盘块可以指定。三层B+树能够存储4千万数据量级别数据。
给哪个数据类型建立索引，key值建立空间越小，数据量存储范围越大，索引建立越小越好。
B+树在叶子节点建立了双向链表，除了从根节点检索，也可以从叶子节点检索。
一般mysql的B+树索引是几层？千万级别的数据量一般3-4层。看索引存储的大小。加一层加16K，现在请求是并发操作。设计索引尽可能保持key值小。
插第一条数据的时候是几层？是2层。插入数据可能影响B+树的树高。
麻烦的问题，索引维护的问题。建了一张表之后，主键要不要设计成自增？最好在不影响业务的时候，尽量让其自增。递增数据页就可以。
插14，分裂，一个块变为2个块。维护成本很高。
InnoDB和MyISAM区别
什么叫存储引擎？不同的存储引擎表示不同的文件在磁盘上的组织形式。
frm表结构，idb为索引和数据。idb为innodb。
MYD表示data,MYI为index。
innodb支持事务，myisam不支持事务，只支持表锁不支持行锁。
5.5以后的版本默认都是innodb
innodb放行记录，mylsam放地址。mylsam数据和索引是分开放的。
面试官不提的话默认为innodb。innodb插记录，默认是包含key值，这个key是什么？可能是主键，可能为唯一键，可能是rowid（6个字节），6个字节的rowid够存吗？int类型占4个字节。4个字节最大超过21亿。
一个表里可以有多少个索引？索引数量没有限制。5种索引5个key。
聚簇索引。数据插入时候必须绑定key值，取决于数据和索引是否是一起存放的，如果是一起存放的则为聚簇索引。主键索引一定是聚簇索引，聚簇索引不一定为主键索引。分开放的为非聚簇索引。
myisam里不包含聚簇索引。
如果name建一个索引，则数据存的是ID。
聚簇索引：数据跟索引是否是一起存放的，聚簇索引的key值可以是主键，也可以是唯一键，也可以是rowid，如果一个表中的普通列创建了索引，那么叶子节点中存放的值是聚簇索引的key值。
刚刚的name列的索引是聚簇索引还是非聚簇索引？非聚簇索引。
select * from 找了两次B+树，第一次是name索引第二次为id索引，回表，select id from 不需要回表的时候叫做覆盖索引。日常使用的时候不要回表。
排序有几种规则？一般是两种，一种是数值序，一种是字典序。
中文排序，asc码排序。字符特别长可以使用hash的方式。
最左匹配：where name = ? and age = ? 把name和age共同作为索引，(name,age)，先匹配name再匹配age。
where name = ? and age = ? √
where name = ? √
where age = ?
where age = ? and name = ? √ mysql优化器优化
索引下推：不好理解。select * from table where name = ? and age = ? 具体的执行顺序。数据存储再存储引擎中,server只负责数据的筛选。
没有索引下推：先根据name的值从存储引擎中把符合条件的都过滤出来，过滤完成之后再sever层对age进行筛选。
有索引下推：直接根据name和age的值从存储引擎中筛选数据，不需要再server做任何处理，减少了server和存储引擎之间的io量。
中间环节都叫做server：连接器等
5.7版本：show variables like '%innodb%'
index_condition_pushdown 索引下推
一个表只有一个聚簇索引
下推：索引server下推到存储引擎。
组合索引，存两个值。先比较第一个再比较第二个。
自己实现排序怎么实现排序。256M内存把1T的文件进行排序怎么做，分治，使用临时文件。
B+树底层叶子节点是排序的。如果使用索引排序的话就不用使用临时文件排序。
查询慢的话，就应该加索引，是加单列索引还是组合索引？需要逐渐摸索。