目录
一、概念
二、索引的优缺点
1、索引的优点
现在假设有这么一个表：
比如，按照 id 这一列建立索引
在数据库上，我们就额外搞了一个空间，维护一些和 id 相关的信息，这里就通过一些特定的数据结构，维护表示 id 相关的索引的情况
后续再按照 id 来查询，就不必再直接遍历了，而是从索引中进行查询，根据索引就能够初步的锁定出数据所在的位置
2、索引的缺陷
1、消耗额外的空间
对于数据库来说，数据都是存储再硬盘上的，索引数据也是在硬盘上的
2、有可能会拖慢增删查改的速度
对于新增来说，此时不光要往表里面写数据，同时还要修改索引
如果删除、修改的条件如果刚好和索引匹配，速度还能快一点
但是如果涉及到索引列的删除 / 修改，这个时候，也要同时维护索引
三、索引的使用
1、查看索引
语法：
show index from 表名;
我们可以看到，目前 student 这个表中存在主键
当表中存在主键的时候，内部就会自动给这个 列 来创建索引
这是因为，主键不允许重复，因此进行插入 / 修改 操作的时候，就需要先查询，看看 插入 / 修改 后的结构是否已经存在
我们可以看到，使用 unique 约束的时候，也会自动生成索引
再重新创建一个 student 表和 class 表相关联
我们可以看到，班级表，由于 classId 是主键，自动生成了一个索引
学生表里面包含了两个索引，其中一个索引是由主键生成的，另一个是由于我们设置了外键约束所自动生成的索引
这是因为，外键这里也涉及到自动查询
1、给学生表中插入一条记录，就需要查询classId 是否在 class 表的 classId 中存在，这个查询就使用到了 class 表中的 classId （主键自动生成的索引）
2、给班级表中删除一条记录，就需要查询 classId 是否在学生表中存在
在上述情况中，主键、unique 、外键 这三种情况都会使 表 自动创建出索引
2、创建索引
语法：
create index 索引名 on 表名(字段名);
此时，就能够看到我们新创建出来的索引
这个创建索引操作可能会非常危险！！！
如果这个表是空的，或者表里面包含的数据本身就不多，创建索引就没事
如果表非空，并且里面包含了非常多的数据，那么创建索引会引起非常大规模的硬盘 IO 操作，进一步就会导致数据库被卡死
3、删除索引
语法：
drop index 索引名 on 表名;
删除索引，只能针对 手动创建的索引，自动生成的索引使不能被删除的
删除索引这个操作也是非常危险的，原因与前面创建索引类似
那么如果现在我们必须给一个已经创建了很多数据的表 创建 / 删除 索引，并且这个数据库还是生产环境的数据库，咋办？
数据库服务器往往也不是单台服务器，为了整个系统的可靠性，通常会搞多个MySQL服务器节点，这些节点的数据都是一样的，能够提高相同的服务（其中某个挂了也不影响大局
先准备好一个新的 MySQL 服务器，把表和索引都创建好，然后把数据都导入过来，再把要替换的MySQL服务器关闭，把新的MySQL 服务器替换上去就行了
四、索引底层的数据结构
MySQL 的索引的数据结构取决于MySQL使用的是哪一个存储引擎
MySQL这个程序，里面包含了很多个模块，有的是负责解析SQLDE ,有的是负责网络通信的，由的是负责存储数据的 ......
存储引擎本质上就是代码里的一个模块（这里包含了若干个代码文件以及一大堆具体的代码）
具体如何存储数据，MySQL支持多种存储方案，innodb 是当下最主流的一种方式
以往我们谈到的数据结构都是内存中的数据结构，但是我们数据库这块组织数据使用的数据结构则是在硬盘上的
内存上的数据结构，对于访问操作是不敏感的（找数据的过程，花时间多，但是真正访问的时候时间不多
硬盘上的数据结构，对于访问操作来说，比较敏感，读写一次硬盘开销远远大于内存
哈希表，O(1) 复杂度 查询 / 插入 / 删除 / 修改数据
但是并不适合数据库的查询场景，这是因为哈希表只能做这种精确查询，没法做模糊查询和范围查询
哈希表需要把指定的 kye 通过 hash 函数映射出一个具体的下标才能定位到具体的位置
红黑树，O(logN)复杂度 查询 / 插入 / 删除 / 修改数据
也不适合数据库的查询场景
元素有序，可以处理范围查询，最大的问题在于红黑树的高度，会在元素个数比较多的适合，变得比较高
B+ 树是为了数据库量身定做的数据结构
注意：当前目前的讨论都是围绕 MySQL 的 innodb 这个存储引擎进行的（其它的存储引擎中可能会用到 hash 作为索引，只能应对这种精准匹配的情况）
要了解 B+ 树，就需要先了解一下 B树
1、B树
B树 有时候会写作 B- 树，- 是连接符，不是减号
B树的核心思路，和之前学过的 " 二叉搜索树 " 差不多，B树 本质上是一个 N叉搜索树
N叉搜索树： 一个节点上可以保存 多个 kye ,N 个 key 就能延伸出 N + 1 个分叉来， N 个 kye 就划分出了 N + 1 个区间
B树查询元素的流程：
1、拿着要查询的元素，从根节点出发， 判定要查找的元素是否在根节点上存在
2、如果不存在，看这个元素是落在哪个区间里，就沿着这个区间的路线往下一个节点上找
3、最终找到叶子节点，还不存在，就是真的存在了
此时，每个节点上，都可以保存多个元素了
当总的元素个数固定的适合，相比于二叉搜索树，涉及到的节点的总数就大大降低了 ，同时树的高度也大大降低了
由此可知，B树的高度是远远小于二叉搜索树的，于是，在进行查询的时候，硬盘IO的次数也就减少了
对于数据库来说，每个节点都需要把数据从硬盘上读出来，才能进行比较
一个节点上有多个 key 和 一个节点上有一个 key ，硬盘IO的开销是差不多的
对于B树来说，在进行插入元素 和 删除元素 的时候，就涉及到 拆分 和 合并
一个节点 可以存多个 key ，但是也不能无限的存，当存储的 key 数量达到一定程度的时候，就需要把这个节点给拆分，把这个节点中的一部分 key 以树的子节点的方式，来进行重新组织，保持当前这个节点中的 key 数量始终不会太多，这样就会衍生出新的节点
2、B+树
B+ 树 才是数据库索引的主角，在B树的基础上，又针对数据库的查询场景做出了一些改进
B+ 树的特点：
上面是B + 树的特点，那么这些特点产生的优势是什么呢？
B+树的优势：
数据库的数据在逻辑意义上是以 "表" 的形式存储的
但是在物理意义上，不需要 “表格” 这样的数据结构，而是直接用 B+ 树 来存储这个表的数据，表格只是用户看起来这像是个表格
此时，非叶子节点的存储空间，消耗是非常小的，可以在内存中缓存一份！！！
此时，进行数据查询的时候，就可以直接通过 内存 来直接进行比较，从而更快速的找到叶子节点上的记录（又一次减少了硬盘IO的次数）
但是B树如果也要把元素存储到每个节点上，非叶子节点就会占据空间比较大，从而无法在内存中缓存了
五、索引事务
1、概念和回滚
事务的本质，就是把多个操作打包成一个操作来完成（让这多个操作，要么全都能执行成功，要么一个都不执行）
注意：一个都不执行，不是真的没有执行，执行是否成功，得执行了才知道
真正执行之前，是不知道在执行具体哪一步的时候会失败
如果是执行到中间的操作出错了，就需要将前面已经成功执行的操作进行还原，还原到最初没有执行的样子，我们将还原到最初没有执行的样子的这个操作称为： 回滚（rollback）
回滚是怎么样实现的呢？
只要把事务中执行的每个操作，通过特定的日志来记录数据库事务操作的中间过程，如果需要回滚，就直接把之前操作的 "逆操作" 来执行就可以了
那如果数据库服务器重启了呢?
因为我们是通过日志来记录事务执行的中间过程的，日志中的数据是始终在硬盘上存在的，即使是数据库服务器重启，就会在重新启动之后，针对之前没有回滚完的情况继续进行处理
2、事务的使用
（1）开启事务
start transaction;（2）执行多条SQL语句
（3）回滚或提交事务
rollback/commit;commit 提交事务：把这些SQL 按照原子的方式来进行执行（带有回滚机制）
rollback 手动触发回滚
一个事务务必要以这两个操作（提交事务和回滚）结尾！！！
如果没有这两个操作，接下里的各种 SQL 操作都会被认为是事务的一部分
3、事务的基本特性
事务的基本特性是非常重要的一个知识点
那么事务的基本特性有哪些呢？
1、原子性 ：保证多个操作被打包成一个整体，要么能全部被正确执行，要么就一个都不执行
2、一致性 ： 保证事务执行之前和事务执行之后，数据能够对上，数据不能离谱
（约束、回滚机制 是保证一致性的重要手段）
3、持久性 ： 事务这里执行的各种操作，都是持久生效的（最终写入到硬盘中的），一旦事务执行成功了，这里的所以操作产生的修改，都是写到硬盘里的
4、隔离性 ： 并发执行事务的时候，隔离性会在执行效率和数据可靠之间做出平衡
"隔离" 描述的是同时执行的事务之间，相互的影响
隔离性越高，并发性就越低，数据越可靠，性能就越低
什么是并发呢？
可以简单理解成：同时执行
数据库是一个客户端 服务器 结构的程序，既然是服务器，服务器就可以同一时刻给多个客户提供服务，这多个客户端，都能够给服务器提交事务
如果提交的这两个事务，是修改不同的数据库 / 不同的表，相互之间是没有什么影响的
如果这两个事务，修改的是同一个表，就可能存在麻烦
当顺序上存在差异的时候，顺序的先后就可能会影响到最终的执行结果，这就是并发执行事务带来的问题
4、并发会遇到的问题
（1）脏读
此外，并发执行事务的时候，还有可能遇到脏读的情况
脏数据：临时的，并非是最终准确的结果
那么如何解决脏读问题？
给 "写" 操作加锁 ，一个事务A 写的时候，其它事务B不能读了，直到事务A 写完数据，提交事务，其它的事务B才能来读取数据
引入了 “写” 加锁，降低了两个事务之间的并发性，提高了隔离性，降低了效率，使数据更准确了
（2）不可重复读
在同一个读取数据的事务中，可能会涉及到多次操作，多个 "读" 操作读到的数据可能会不一样
如何应对不可重复读？
给 "读" 操作也加锁
给 "写" 操作加锁的意思：我在写的时候，别人不能读（除非使我写完提交，别人才能读），此时，别人读的过程中，我还可以再开启一个事务来写，第二个事务提交之前，其它读的事务读到的就是新版本数据了
给 "读" 操作加锁的意思：别人读的时候，我不能写了。
这个时候，并发程度又进一步降低了（执行效率降低了），隔离性进一步提高了（数据更可靠了）
（3）幻读
一个事务，在多次读的过程中，虽然多次读的数据的值是一样的但是结果集不同
比如：第一次读是10条记录，第二次读是11条记录，这11条记录中的10条和之前的10条是一模一样的，但是多出来一个，我们称为幻读
可以视为，是不可重复读的特殊情况
如何解决幻读？
办法只有一个： 串行化
彻底放弃并发执行事务，所有的事务都是一个挨着一个的串行执行（执行完一个事务，再执行下一个事务）
5、隔离级别
MySQL 提供了四种事务的隔离级别，MySQL可以配置自己的隔离级别是哪一个
1、read uncommitted (RU) 允许读未提交的数据（脏读、不可重复度、幻读），隔离性最低，并发程度最高，数据可靠性最低，效率最高
2、read commmittded (RC) 允许读取已经提交了的数据（给写加锁了），解决脏读、存在不可重复读和幻读，隔离性提高了，并发性降低了，数据可靠性提高了，效率降低了
3、repeatable read （RR）默认的隔离级别，可以重复读取数据（给写操作和读操作都加锁），解决了脏读和不可重复读的问题，存在幻读问题，隔离性又提高了，并发性又降低了，数据可靠性又提高了，效率又降低了
4、serializable 事务彻底的串行执行，解决了脏读、不可重复读、幻读的问题，隔离性最高，并发性最低（没有），数据最可靠，效率也最低
4219
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
