BTree

聚簇索引并不是一种单独的索引类型，而是一种数据存储方式(不是数据结构，而是存储结构)，具体细节依赖于其实现方式，但innodb的聚簇索引实际上是在同一个结构中保存了BTree(B-Tree ,B+Tree)索引和数据行。 https://blog.csdn.net/u013235478/article/details/50625677 这个链接里介绍了BTree索引 聚簇索引（clustered index）也称为聚集索引，聚类索引，簇集索引，聚簇索引确定表中数据的物理顺序。 聚集索引：类似字典的拼音目录。表中的数据按照聚集索引的规则来存储的。就像新华字典。整本字典是按照A-Z的顺序来排列。这也是一个表只能有一个聚集索引的原因。因为这个特点，具体索引应该建在那些经常需要order by,group by,按范围取值的列上。因为数据本身就是按照聚集索引的顺序存储的。不应该建在需要频繁修改的列上，因为聚集索引的每次改动都以为这表中数据的物理数据的一次重新排序。 聚集索引默认是按照每张表的主键构造一棵B+Tree(平衡查询树)，树中的叶子节点存放着表中的行记录数据，因此，也将聚集索引的叶子节点称为数据页；非叶子节点中存放着仅仅是键值和指向叶子节点的偏移量。每个叶子节点（数据页）都通过一个双向链表进行连接。 由于实际的数据页只能按照一棵B+树进行排序，因此数据库中每张表只能有一个聚集索引。

二叉搜索树 1.所有非叶子结点至多拥有两个儿子（Left和Right）； 2.所有结点存储一个关键字； 3.非叶子结点的左指针指向小于其关键字的子树，右指针指向大于其关键字的子树 二叉平衡树 它是一棵空树或它的左右两个子树的高度差的绝对值不超过1，并且左右两个子树都是一棵平衡二叉树. 由于普通的二叉查找树会容易失去”平衡“，极端情况下，二叉查找树会退化成线性的链表，导致插入和查找的复杂度下降到 O(n) ，所以，这也是平衡二叉树设计的初衷。 二叉树，它的搜索时间复杂度为 O(log2N) ，所以它的搜索效率和树的深度有关，如果要提高查询速度，那么就要降低树的深度。 要降低树的深度，很自然的方法就是采用多叉树，再结合平衡二叉树的思想，我们可以构建一个平衡多叉树结构，然后就可以在上面构建平衡多路查找算法，提高大数据量下的搜索效率。 B-树 定义: 1. 有一个根节点，根节点只有一个记录和两个孩子或者根节点为空； 2. 每个节点记录中的key和指针相互间隔，指针指向孩子节点； 3. d是表示树的宽度，除叶子节点之外，其它每个节点有[d/2,d-1]条记录，并且些记录中的key都是从左到右按大小排列的，有[d/2+1,d]个孩子； 4. 在一个节点中，第n个子树中的所有key，小于这个节点中第n个key，大于第n-1个key

要回答好这个问题，首先我们要弄懂什么是索引？索引常见的数据结构有哪些？这些数据结构有何优缺点？只有弄懂这些，再去比较，才会知道为啥要用B+树作为MySQL数据库的存储索引了。 一、索引是什么？ MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构。它的本质就是 数据结构 ，单独存储在磁盘上，用它来提高数据查询的效率。 适合作为索引的结构应该是尽可能少的执行磁盘IO操作，因为执行磁盘IO操作非常的耗时。 二、索引常见数据结构 2.1 二叉查找树（Binary Search Tree） 采取二分查找的思想，O（log N）的复杂度就可以完成对数据的查找任务，查找所需的最大次数等同于二叉查找树的高度。 它具有以下特性： 左子树上所有结点的值均小于或等于它的根结点的值； 右子树上所有结点的值均大于或等于它的根结点的值； 左、右子树也分别为二叉排序树。 如下图所示： 排序工具 对该二叉树的节点进行查找发现深度为1的节点的查找次数为1，深度为2的查找次数为2，深度为n的节点的查找次数为n，因此其平均查找次数为 (1+2+2+3+3+3) / 6 = 2.3次 二叉查找树可以任意地构造，这样会出现一种极端情况，如果依次插入如下六个节点：7，6，5，4，那么就会变成下图所示： 这样退化成线性表，导致树高度过高，从而查询效率就降低了。

索引 是帮助MySQL高效获取的数据的 排好序 的 数据结构 B Tree 结构 叶子节点具有相同的深度，叶子节点的指针为空， 所有索引元素不重复， 叶子节点的数据从左往右递增排列 B+Tree 索引 非叶子节点不存储data，只存储索引，可以放更多索引 叶子节点包含所有的索引字段， 叶子之间使用指针链接（单向），提高区间访问性能 MySQL所使用的 B+Tree索引，经过了改造，叶子节点之家使用双向指针链接 。 默认一个节点大小为16kb MyISAM 存储引擎 非聚集索引，索引文件和数据分离，叶子节点里面data，存储的是数据地址 InnoDb 存储引擎 主键索引属于聚集索引，叶子节点data里面包含了完整的数据记录 非主键索引属于非聚集索引，为了数据的一致性和节省存储空间，叶子节点data里面存储了主键ID Hash 索引 根据查询key值，通过hash算法，以及hash表，直接可以定位到数据存储的地址，效率非常高，不受数据量影响 不支持模糊查询，不支持范围查询，不支持排序 联合索引结构 按照创建联合主键几个字段的顺序进行排序，组合保存在B+Tree的叶子节点 来源： https://my.oschina.net/u/3519302/blog/3128263

SQL优化背景 开发项目上线初期，由于业务数据量相对较少，一些SQL的执行效率对程序运行效率的影响不太明显，而开发和运维人员也无法判断SQL对程序的运行效率有多大，故很少针对SQL进行专门的优化，而随着时间的积累，业务数据量的增多，SQL的执行效率对程序的运行效率的影响逐渐增大，此时对SQL的优化就很有必要。 SQL优化发生在业务量达到一定规模的时候 目的是优化SQL的执行效率 MySQL 优化 优化范围 硬件资源 操作系统参数，数据库参数配置 SQL语句，索引优化 SQL优化 数据库设计优化【规范，前期设计】 SQL语句优化 索引优化 读写分离，分库分表 慢查询语句 慢查询：10s无返回结果，定义为慢查询 SHOW STATUS LIKE "slow_queries"; SHOW VARIABLES LIKE "long_query_time";//可以显示当前慢查询时间 set long_query_time=1 ;//可以修改慢查询时间 常用优化方法 查询优化 避免全表扫描（考虑在 where 及 order by 涉及的列上建立索引） 尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描 select id from t where num is null 可以在num上设置默认值0，确保表中num列没有null值

典型的3种存储引擎 1、hash： 代表：nosql的redis/memcached 本质为： 基于(内存中)的hash； 所以支持 随机 的增删查改，读写的时间复杂度O(1)； 但是无法支持顺序读写(注，这里指典型的hash，不是指如redis的基于跳表的zset的其他功能)； 基本效果：在不需要有序遍历时，最优 2、磁盘查找树： 代表：mysql 本质为：基于(磁盘的)顺序查找树，B树/B+树； 基本效果：支持有序遍历；但数据量很大后，随机读写效率低(原因往下看)； 3、lsmtree： 代表：hbase/leveldb/rocksdb 本质为： 实际落地存储的数据按key划分，形成有序的不同的文件； 结合其“先内存更新后合并落盘”的机制，尽量达到磁盘的写是顺序写，尽可能减少随机写； 对于读，需合并磁盘已有历史数据和当前未落盘的驻于内存的更新，较慢； 基本效果：也可以支持有序增删查改；写速度大幅提高；读速度稍慢； B树 B树是一种平衡多路搜索树，B树与红黑树最大的不同在于，B树的结点可以有多个子女，从几个到几千个。那为什么又说B树与红黑树很相似呢?因为与红黑树一样，一棵含n个结点的B树的高度也为O（lgn），但可能比一棵红黑树的高度小许多，应为它的分支因子比较大。所以，B树可以在O（logn）时间内，实现各种如插入（insert），删除（delete）等动态集合操作。

多路查找树(muitl-way search tree) ，其每一个节点的孩子数可以多于两个，且每一个节点处可以存储多个元素。主要有4中特殊形式。 一、2-3树 定义：其中的每一个节点都具有两个孩子（称为2节点）或者三个孩子（称为3节点）。 并且2-3树中所有的叶子都在同一层上。 一个2节点包含一个元素和两个孩子（或者没有孩子）。 一个3节点包含一小一大两个元素和三个孩子（或者没有孩子）。 1. 2-3树的插入实现 1）对于空树，插入一个2节点即可； 2）插入节点到一个2节点的叶子上。由于本身就只有一个元素，所以只需要将其升级为3节点即可。 3）插入节点到一个3节点的叶子上。因为3节点本身最大容量，因此需要拆分，且将树中两元素或者插入元素的三者中选择其一向上移动一层。 三种情况： 升级父节点 升级根节点 增加树高度 2. 2-3树的删除实现 1）所删元素位于一个3节点的叶子节点上，直接删除，不会影响树结构。 2）所删元素位于一个2节点上，直接删除，破坏树结构。 分为四种情况： 此节点双亲也是2节点，且拥有一个3节点的右孩子； 此节点的双亲是2节点，它右孩子也是2节点； 此节点的双亲是3节点； 当前树是一个满二叉树，降低树高； 3）所删元素位于非叶子的分支节点。此时按树中序遍历得到此元素的前驱或后续元素，补位。 分支节点是2节点 分支节点是3节点 二、2-3-4树 2-3-4树是2

一、LSM-Tree概述 核心思想就是放弃部分读能力，换取写入能力的最大化。LSM-Tree ，这个概念就是结构化合并树（Log-Structured Merge Tree）的意思，它的核心思路其实非常简单，就是假定内存足够大，因此不需要每次有数据更新（插入、删除）就必须将数据写入到磁盘中，而可以先将最新的数据驻留在内存中，等到积累到一定限制大小之后，再使用归并排序的方式将内存中的数据合并追加到磁盘队尾(因为所有待合并的树都是有序的，可以通过合并排序的方式快速合并到一起)。 磁盘的技术特性:对磁盘来说，能够最大化的发挥磁盘技术特性的使用方式是:一次性的读取或写入固定大小的一块数据，并尽可能的减少随机寻道这个操作的次数。 日志结构的合并树（LSM-tree）是一种基于硬盘的数据结构，与B+ tree相比，能显著地减少硬盘磁盘寻道开销，并能在较长的时间提供对文件的高速插入（删除）。然而LSM-tree在某些情况下，特别是在查询需要快速响应时性能不佳。通常LSM-tree适用于索引插入比检索更频繁的应用系统。 二、LSM-Tree VS B+ Tree B+Tree RDBMS一般采用B+树作为索引的数据结构。RDBMS中的B+树一般是3层n路的平衡树。B+树的节点对应于磁盘数据块。因此对于RDBMS，数据更新操作需要5次磁盘操作（从B+树3次找到记录所在数据块，再加上一次读和一次写）

B-Tree是为磁盘等外存储设备设计的一种平衡查找树。先了解磁盘的相关知识: 1.系统从磁盘读取数据到内存时是以磁盘块为基本单位的，位于同一磁盘块中的数据会被一次性的读取出来，而不是需要什么读取什么。 2.InnerDB存储引擎中是有页(Page)的概念，页是其管理的最小单位。默认每页的大小为16KB，可以设置。InnerDB在把磁盘数据读入内存的时候，会以页为基本单位。B-Tree的结构可以让系统高效的找到数据所在的磁盘块。 来源： https://my.oschina.net/u/3126880/blog/3111485

索引是帮助mysql获取数据的数据结构。最常见的索引是Btree索引和Hash索引。 不同的引擎对于索引有不同的支持：Innodb和MyISAM默认的索引是Btree索引；而Mermory默认的索引是Hash索引。 我们在mysql中常用两种索引算法BTree和Hash，两种算法检索方式不一样，对查询的作用也不一样。 一、BTree BTree索引是最常用的mysql数据库索引算法，因为它不仅可以被用在=,>,>=,<,<=和between这些比较操作符上，而且还可以用于like操作符，只要它的查询条件是一个不以通配符开头的常量，例如： select * from user where name like ‘jack%’; select * from user where name like ‘jac%k%’; 如果一通配符开头，或者没有使用常量，则不会使用索引，例如： select * from user where name like ‘%jack’; select * from user where name like simply_name; 二、Hash Hash索引只能用于对等比较，例如=,<=>（相当于=）操作符。由于是一次定位数据，不像BTree索引需要从根节点到枝节点，最后才能访问到页节点这样多次IO访问，所以检索效率远高于BTree索引。