13518219792
个人能力有限，如有错误请指出，共同学习。
创新互联公司-专业网站定制、快速模板网站建设、高性价比青白江网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式青白江网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖青白江地区。费用合理售后完善，十载实体公司更值得信赖。
二叉树
B树
B+树
特点：
聚簇索引
二级索引
key数据存储量估算：
若每个页可以存1000个key，而且树的高度是4，那么
前提条件如下：
插入步骤
步骤一
因为索引中还没有数据，所以此时的B+树只有一个空的根结点，又由于一个页只能存3个key，首先将10，20，5插入进去（实际上此步发生了3次插入），然后在页面内做数据排序，最终结果如下图：
步骤二：
由于根页面已经写满，此时插入8，将发生分裂（根页面分裂），大致步骤如下：
注意：在分裂过程中，根结点始终是不会变的，不管变成多大的树，根结点的页面号始终如一。
步骤五：
插入数据40，发现比根结点23大，找到103号页面，发现已满，执行分裂，分裂同上面叶子结点的分裂步骤。分裂后如图所示：
步骤六：
继续插入下一个数据9，因为比20小，找到101号页面，发现已满，需要做叶子结点分裂，如下图：
传统B+树的数据删除，一般都会有一个所谓的填充因子，来控制页面数据的删除比例，如果数据量小于这个填充因子所表示的数据量，就会有节点合并，这与分裂是相对应的。
InnoDB的实现与传统B+树算法有不同之处，InnoDB在删除索引数据时，会先检查当前页剩余的记录数，如果只剩下一条记录，就会直接将这个页面从B+树中摘除，也只有这种情况，InnoDB才会回收一个页面，InnoDB的页面没有合并一说，但是对于根节点，即使索引数据全部删除，根节点页依然存在，只不过是以空页的形式存在。
下面举个例子描述索引删除过程，前提条件与前面插入记录时一致。
删除数据 50
删除过程全部结束，最终得到一个空的索引页。
《MySQL运维内参》
B+树动画演示：
聚集索引可以用b树实现。
简介：
B+树中只有叶子节点会带有指向记录的指针，而B树则所有节点都带有。
B+树索引可以分为聚集索引和非聚集索引。
mysql使用B+树，其中Myisam是非聚集索引，innoDB是聚集索引。
聚簇索引索引的叶节点就是数据节点；而非聚簇索引的叶节点仍然是索引节点，只不过有一个指针指向对应的数据块。
B+ 树的特点:
（1）所有关键字都出现在叶子结点的链表中(稠密索引)，且链表中的关键字恰好是有序的。
（2）不可能在非叶子结点命中。
（3）非叶子结点相当于是叶子结点的索引(稀疏索引)，叶子结点相当于是存储(关键字)数据的数据层。
为什么Mysql考虑使用B+树，而不是B树，其实我们可以先了解下B树和B+树的特点来看下。
※ 树的每个结点都会存储数据
※ 单次查询不一定要遍历到树的根部，平均查询时间会比较快
※ 非叶子节点不存储数据，只存储（冗余）索引，索引包含主键和指针
※ 叶子节点才真正存储数据
※ 每个叶子节点互相链表相连，保证了范围查询的时效性(页之间用双向链表连接，数据间用单项链表链接)
InnoDB最小存储单位是页，叶子节点和非叶子节点最小单位都是页，页大小Mysql 默认设定16384字节，约为16KB。
我们假设主键ID为bigint类型，长度为8字节，而指针大小在InnoDB源码中设置为6字节，这样一共14字节
我们一个页中能存放多少这样的索引元素，其实就代表有多少指针，即16384/14=1170;
高度为2的B+树能存放1170×16=18720
高度为3的B+树能存放1170×1170×16 = 21902400
InnoDB中B+树高度一般为1-3层，它就能满足千万级的数据存储。
在查找数据时一次页的查找代表一次IO，所以通过主键索引查询通常只需要1-3次IO操作即可查找到数据。
理解Mysql索引的原理和数据结构有助于我们更好的使用索引以及进行SQL优化，索引是在存储引擎层面实现的，所以不同的引擎实现的索引也有一定的区别，但是在生产环境中，我们最常用的就是InnoDB引擎和B树索引，OK，那本文要讨论的重点也同样是 InnoDB引擎下的B树索引 。
我们建立一个表来进行测试，表的DDL如下所示，我们要关注的是表t_book上的主键索引id和name author publish_date三列组成的索引test_index。
Mysql中的B树索引是使用B+树实现的，关于B+树的数据结构个人认为美团点评技术博客中Mysql索引原理及慢查询优化一文中介绍的非常详实，B+树的数据结构如下图所示。
图中浅蓝色块即磁盘块，根节点磁盘块中存储17和35两个数据，其中指针P1指向小于17的数据，指针P2指向大于17小于35的数据，指针P3指向大于35的数据。显然通过B+树索引查询数据与B+树的高度有关，如上图的B+树索引查找一个叶子节点的数据只需要三次磁盘IO，对于Mysql来说三层的B+树可以索引上百万的数据，这对于查询效率的提升是巨大的。
总结起来Mysql中B树索引有以下关键特点：
Mysql中的B树索引有两种数据存储形式，一种为聚簇索引，一种为二级索引。
InnoDB一般会使用表的主键来作为聚簇索引，如果一个表没有主键（不建议这么玩）InnoDB会选用一个唯一非空索引来代替，如果没有这样的索引，InnoDB会隐式建立一个聚簇索引。聚簇的含义即是数据行和相邻的键值紧凑的存储在一起，占据一块连续的磁盘空间，因此通过聚簇索引访问数据可以有效减少随机IO，通常使用聚簇索引查找比非聚簇索引查找速度更快。以我们建立的表t_book为例，聚簇索引即为自增主键id，其B树索引数据结构可以用下图来表示。
聚簇索引有以下关键特点：
InnoDB的B树索引中除了聚簇索引，就都是二级索引了，二级索引的含义是索引的叶子节点除了存储了索引值，还存储了主键id，在使用二级索引进行查询时，查找到二级索引B树上的叶子节点后还需要去聚簇索引上去查询真实数据，但是这里有一种特殊情况，即查询所需的所有字段在二级索引中都可以获取，此时就不需要再去回表查数据了，这种情况就是索引覆盖（EXPLAIN中EXTRA列中会出现USING INDEX，本文只关注索引结构，不详细讨论索引覆盖等技术的使用，如果深入理解索引的数据结构，索引覆盖等技术也没有那么神秘）。
在我们的测试表t_book中，test_index即为二级索引，由于我们把除了主键id所有的列都作为一个联合索引，所以在这个表上的查询都可以使用索引覆盖技术，但是具体生产环境中也不建议总是采用这种做法，索引列的增加也会增大插入更新数据时的索引更新成本，具体的优化要视具体情况决策。t_book上的二级索引test_index的索引结构由下图表示。
通过以上结构，我们可以推断出二级索引的以下关键特点：
索引覆盖：
最左前缀匹配：
二级索引可以说是我们在Mysql中最常用的索引，通过理解二级索引的索引结构可以更容易理解二级索引的特性和使用。
最后聊点轻松的索引结构，哈希索引就是通过哈希表实现的索引，即通过被索引的列计算出哈希值，并指向被索引的记录。
哈希索引有如下特性：
Mysql索引原理及慢查询优化
高性能Mysql 第三版
MySQL是一个关系型数据库管理系统，由瑞典MySQL AB公司开发，属于Oracle旗下产品，是最流行的关系型数据库管理系统之一。
端口是3306。
表很多时，使用linux脚本，需要根据需要修改一下：
和创建一样，可以加上 if exists
可两篇文章：
如：
用于在已有的表中添加、删除或修改列。
添加 ADD
或
默认是添加到最后，但可以指定位置。 FIRST ：添加最前
AFTER 字段名 ：添加指定字段之后
例子：
删除 DROP
修改 MODIFY 主要修改原列的类型或约束条件 同样可以用 FIRST 和 AFTER 字段名 ，代表的是修改到哪里。
修改字段名 CHANGE
可以把表2的数据复制到表1中，但 不能复制约束性条件 。
单行
多行，注意 只有一个VALUES ：
不写 (行1, 行2...) 这一部分的话，默认一一对应
除了以上方法外，还可以用SET为每一行附上相应的值。
假如没有筛选的话，就给全部都修改了。可以用 WHERE 筛选。
假如 没有筛选的话，就给全部删除了 。相当于清空。
清空
先把表删除，然后再建一个。与 DELETE FROM 相比， TRUNCATE 的效率更快，因为 DELETE FROM 是把记录逐条删除的。
查询执行的顺序
FROM -- WHERE -- SELECT -- GROUP BY -- HAVING -- ORDER BY -- LIMIT
注意
当数据很大，上百万的时候，使用LIMIT ... OFFSET ..的方式进行分页十分浪费资源且耗时长。最好是结合WHERE使用，如：
REGEXP 使用正则表达进行匹配。 查询时，需要搭配WHERE或HAVING使用 。
两个表之间有交集且要用到两个表的数据时，可以使用内连接查询。
LEFT JOIN 关键字从左表（table1）返回所有的行，即使右表（table2）中没有匹配。如果右表中没有匹配，则结果为 NULL。
用法：
RIGHT JOIN 关键字从右表（table2）返回所有的行，即使左表（table1）中没有匹配。如果左表中没有匹配，则结果为 NULL。 把LEFT JOIN的表1、表2调换顺序，就是REGHT JOIN 。
FULL OUTER JOIN 关键字只要左表（table1）和右表（table2）其中一个表中存在匹配，则返回行. 相当于结合了 LEFT JOIN 和 RIGHT JOIN 的结果。
但 MySQL中不支持 FULL OUTER JOIN 。
即SELECT嵌套。
IN 一个查询结果作为另一个查询的条件。 如：
EXISTS 用于判断查询子句是否有记录，如果有一条或多条记录存在返回 True，否则返回 False。True时执行。 如：
索引的本质是一种排好序的数据结构。利用索引可以提高查询速度。
常见的索引有：
MySQL通过外键约束来保证表与表之间的数据的完整性和准确性。 外键的使用条件：
外键的好处：可以使得两张表关联，保证数据的一致性和实现一些级联操作。
对已有的两个表增加外键 比如：主表为A，子表为B，外键为aid，外键约束名字为a_fk_b
为子表添加一个字段，当做外键
为子表添加外键约束条件
假如删除记录报错： [Err] 1451 -Cannot deleteorupdatea parent row: aforeignkeyconstraintfails (...)
这是因为MySQL中设置了foreign key关联，造成无法更新或删除数据。可以通过设置 FOREIGN_KEY_CHECKS 变量来避免这种情况。 第一步：禁用外键约束，我们可以使用： SETFOREIGN_KEY_CHECKS=0; 第二步：删除数据 第三步：启动外键约束，我们可以使用： SETFOREIGN_KEY_CHECKS=1; 查看当前FOREIGN_KEY_CHECKS的值，可用如下命令： SELECT @@FOREIGN_KEY_CHECKS;
使用 UNION 来组合两个查询，如果第一个查询返回 M 行，第二个查询返回 N 行，那么组合查询的结果一般为 M+N 行。
每个查询必须包含相同的列、表达式和聚集函数。
默认会去除相同行，如果需要 保留 相同行，使用 UNION ALL 。
只能包含一个 ORDER BY 子句，并且必须位于语句的最后 。
内置函数很多, 见: MySQL 函数
我们一般使用 START TRANSACTION 或 BEGIN 开启事务, COMMIT 提交事务中的命令, SAVEPOINT : 相当于设置一个还原点, ROLLBACK TO : 回滚到某个还原点下
一般的使用格式如下:
开启事务时, 默认加锁
根据类型可分为共享锁（SHARED LOCK）和排他锁（EXCLUSIVE LOCK）或者叫读锁（READ LOCK）和写锁（WRITE LOCK）。
根据粒度划分又分表锁和行锁。表锁由数据库服务器实现，行锁由存储引擎实现。
除此之外,我们可以显示加锁
加锁时, 如果没有索引，会锁表，如果加了索引，就会锁行
InnoDB默认支持行锁，获取锁是分步的，并不是一次性获取所有的锁，因此在锁竞争的时候就会出现死锁的情况
解决方法:
即ACID特性:
由于并发事务会引发上面这些问题, 我们可以设置事务的隔离级别解决上面的问题.
MySQL的默认隔离级别（可重复读）
查看当前会话隔离级别
方式1
方式2
设置隔离级别
主从集群的示意图如下:
主要涉及三个线程： binlog 线程、 I/O 线程和 SQL 线程。
同步流程:
由于MySQL主从集群只会从主节点同步到从节点, 不会反过来同步, 所以需要读写分离
读写分离需要在业务层面实现 , 写数据只能在主节点上完成, 而读数据可以在主节点或从节点上完成
索引是帮助MySQL高效获取数据的排好序的数据结构
MySQL的索引有
推荐两个在线工具:
简单来说, B树是在红黑树(一个平衡二叉树)的基础上将一个节点存放多个值, 实现的, 降低了树的高度, 每个节点都存放索引及对应数据指针, 同一层的节点是递增的
而B+树在B树的基础上进行优化, 非叶子节点存放 子节点的开始的索引, 叶子节点存放索引和数据的指针, 且叶子节点之间有双向的指针
如下示意图:
不同的引擎, 主键索引存放的数据也不一样, 比如常见的 MyISAM 和 InnoDB
MyISAM 的B+树叶子节点存放表数据的指针, InnoDB 的B+树叶子节点存放处主键外的数据
其他的:
即多个列组成一个索引, 语法:
由于联合索引的B+树的结构, 根据列建立, 所以我们的查找条件也要根据索引列的顺序( where column1=x, column2=y,columnN... ), 否则会全表扫描
如果你对列进行了 （+，-，*，/，!） , 那么都将不会走索引。
OR 引起的索引失效
OR 导致索引是在特定情况下的，并不是所有的 OR 都是使索引失效，如果OR连接的是 同 一个字段，那么索引 不会失效 ， 反之索引失效 。
这个我相信大家都明白，模糊搜索如果你前缀也进行模糊搜索，那么不会走索引。
这两种用法，也将使索引失效。另 IN 会走索引，但是当IN的取值范围较大时会导致索引失效，走全表扫描, 见: MySQL中使用IN会不会走索引
不走索引。
走索引。
所以设计表的时候, 建议不可为空, 而是将默认值设置为 "" ( NOT NULL DEFAULT "" )
MySQL的Innodb存储引擎的索引分为聚集索引和非聚集索引两大类
特点：B+树叶子节点存储行数据
一个表中，必须有一个聚集索引，只能有一个聚集索引，Innodb通常把一个表的主键索引作为聚集索引，如果没有主键InnoDB会选择一个唯一索引代替。如果没有这样的索引，InnoDB会隐式的定义一个主键来作为聚集索引，这个字段为6个字节，类型为长整形。
利用主键索引查找行数据是最快的，建议使用自增主键原因是利于索引树的构建（主键自增写入时新插入的数据不会影响到原有页，插入效率高；但是如果主键是无序的或者随机的，那每次的插入可能会导致原有页频繁的分裂，影响插入效率）
特点：B+树叶子节点存储主键ID
一个表中可以有多个非聚集索引，每个非聚集索引即是一棵B+树
通过非聚集索引查找数据时，需要先在非聚集索引上找到主键ID，再从聚集索引获取行数据，这个过程就称之为回表
B树索引中的B树实际上是B+树，至于为什么使用B+树而不使用B树或者红黑树的原因在另外的文章中有提及。
特点：
特点：类似JDK中的HashMap，但无法支持范围查询
特点：使用的算法仍然是B树索引，不同的就是索引列的值必须唯一
对于普通索引来说，查找到满足条件的第一个记录后，需要查找下一个记录，直到碰到第一个不满足条件的记录。
对于唯一索引来说，由于索引定义了唯一性，查找到第一个满足条件的记录后，就会停止继续检索，提升索引性能
另外插入行时会构建该唯一索引，假如索引值重复将插入失败，适合业务上做唯一性检验
通过建立倒排索引，可以极大的提升检索效率,解决判断字段是否包含的问题，但是业务上一般都不采用这种索引，而是使用ES处理全文搜索需求
仅对某个特定字段建立的索引，如(biz_id)
对多个字段建立的索引，如(biz_id,type)
