根据极客时间 MySQL四十五讲 基础篇知识点汇总
认准 林晓斌老师
先把赊账的金额记录在粉板上，等不忙了再记录到账本
有了 redo log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为 crash-safe
crash-safe
为了让数据在逻辑上一致
1.写入 redo log Prepare 阶段 – > 2.写入 binlog – > 3.Commit 提交
redo log 用于保证 crash-safe 能力。innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候，表示每次事务的 redo log 都直接持久化到磁盘。这个参数我建议你设置成 1，这样可以保证 MySQL 异常重启之后数据不丢失。
sync_binlog 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。这个参数我也建议你设置成 1，这样可以保证MySQL 异常重启之后 binlog 不丢失。
ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔离性、持久性）
当数据库同时执行多个事务的时候 避免出现 脏读（dirty read）、不可重复读（non-repeatable read）、**幻读（phantom read）**的问题。
SQL 标准的事务隔离级别：读未提交（read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（serializable ）。
Oracle 数据库的默认隔离级别其实就是“读提交”
每条记录在更新的时候都会同时记录一条回滚操作。同一条记录在系统中可以存在多个版本，这就是数据库的多版本并发控制（MVCC）
举个例子：
如果这样的话，那么回滚日志肯定会很大，不过不用担心，
回滚日志会删除的！
那好 什么时候它会删除呢 ？？？
系统会判断当没有事务需要用到这些回滚日志的时候，回滚日志会被删除
那好 什么又是不需要的时候呢？？？
当系统里么有比这个回滚日志更早的 read-view 的时候
注意：尽量不要使用长事务
那好 这又是 为什么呢？？？
长事务意味着系统里面会存在很老的事务视图，在这个事务提交之前，回滚记录都要保留，这会导致大量占用存储空间。除此之外，长事务还占用锁资源，可能会拖垮库。
举个例子：
我们来看看在不同的隔离级别下，事务 A 会有哪些不同的返回结果，也就是图里面 V1、V2、V3 的返回值分别是什么。
索引的作用：提高数据查询效率
常见索引模型：哈希表、有序数组、搜索树
思路：
哈希表是一种以键 - 值（key-value）存储数据的结构，我们只要输入待查找的值即 key，就可以找到其对应的值即 Value。哈希的思路很简单，把值放在数组里，用一个哈希函数把 key 换算成一个确定的位置，然后把 value 放在数组的这个位置。如何解决冲突：
多个 key 值经过哈希函数的换算，会出现同一个值的情况。处理这种情况的一种方法是，拉出一个链表。
实用场景：
哈希表这种结构适用于只有等值查询的场景
思路：
有序数组：按顺序存储。查询用二分法就可以快速查询，时间复杂度是：O(log(N))
效率：
有序数组查询效率高，更新效率低
适用场景：
序数组索引只适用于静态存储引擎
思路：
每个节点的左儿子小于父节点，父节点又小于右儿子
时间复杂度：
查询时间复杂度 O(log(N))，更新时间复杂度 O(log(N))
数据库存储大多不适用二叉树，因为树高过高，会适用 N 叉树
注意：
数据库存储大多不适用二叉树，因为树高过高，会适用 N 叉树
主键索引的叶子节点存的是整行数据 主键索引也被称为聚簇索引（clustered index）。
非主键索引的叶子节点内容是主键的值 非主键索引也被称为二级索引（secondary index）。
主键索引只要搜索 ID 这个 B+Tree 即可拿到数据。普通索引先搜索索引拿到主键值，再到主键索引树搜索一次(回表)
基于非主键索引的查询需要多扫描一棵索引树
主键长度越小，普通索引的叶子节点就越小，普通索引占用的空间也就越小。注意：
- 一个数据页满了，按照 B+Tree 算法，新增加一个数据页，叫做页分裂，会导致性能下降。空间利用率降低大概 50%。当相邻的两个数据页利用率很低的时候会做数据页合并，合并的过程是分裂过程的逆过程。
- 从性能和存储空间方面考量，自增主键往往是更合理的选择。
再搜索的过程中 我们在非主键索引查询时，回到主键的过程 称之为 回表
如果查询的数据可以直接提供结果，不需要回表，那么称之为 覆盖索引
例如：select ID from T where k between 3 and 5
如果执行的语句是 select ID from T where k between 3 and 5，这时只需要查 ID 的值，而 ID的值已经在 k 索引树上了，因此可以直接提供查询结果，不需要回表。也就是说，在这个查询里面，索引 k 已经“覆盖了”我们的查询需求，我们称为覆盖索引。
注意： 由于覆盖索引可以减少树的搜索次数，显著提升查询性能，所以使用覆盖索引是一个常用的性能优化手段。
顾名思义，全局锁就是对整个数据库实例加锁
MySQL 提供了一个加全局读锁的方法，命令是
Flush tables with read lock (FTWRL)
当你需要让整个库处于只读状态的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞：
使用场景:
全局锁的使用场景典型是，做全库逻辑备份。也就是把整库每个表都 select 出来存成文本。
MySQL 里面表级别的锁有两种：一种是表锁，一种是元数据锁（meta data lock，MDL)。
表锁的语法是
lock tables … read/write。
可以用 unlock tables 主动释放锁，也可以在客户端断开的时候自动释放。
在还没有出现更细粒度的锁的时候，表锁是最常用的处理并发的方式。
而对于 InnoDB 这种支持行锁的引擎 一般不使用 lock tables 命令来控制并发，毕竟锁住整个表的影响面还是太大。
MDL 不需要显式使用，在访问一个表的时候会被自动加上
MDL 的作用是，保证读写的正确性。
全局锁主要用在逻辑备份过程中。对于全部是 InnoDB 引擎的库，我建议你选择使用–single-transaction 参数，对应用会更友好。
表锁一般是在数据库引擎不支持行锁的时候才会被用到的。如果你发现你的应用程序里有 lock tables 这样的语句，你需要追查一下，比较可能的情况是：
MDL 会直到事务提交才释放，在做表结构变更的时候，你一定要小心不要导致锁住线上查询和更新。
行锁就是针对数据表中行记录的锁
解释：
比如事务 A 更新了一行，而这时候事务 B 也要更新同一行，则必须等事务 A 的操作完成后才能进行更新。
在 InnoDB 事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议。
当数据量大的时候 行锁就会造成锁的冲突，这个时候 我们就需要 来降低这个并发冲突
当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态，称为死锁
当出现死锁以后，有两种策略：
首先 我们需要知道这个 ： 死锁检测也是有额外负担的
那我们来举个例子说明一下：
每个新来的被堵住的线程，都要判断会不会由于自己的加入导致了死锁，这是一个时间复杂度是 O(n) 的操作。假设有 1000 个并发线程要同时更新同一行，那么死锁检测操作就是 100 万这个量级的。虽然最终检测的结果是没有死锁，但是这期间要消耗大量的 CPU 资源。因此，你就会看到 CPU 利用率很高，但是每秒却执行不了几个事务。
怎么解决由这种热点行更新导致的性能问题呢？
既然说到事务隔离 那么我们 首先得知道 MySQL是事务隔离的还是 不隔离的 对吧？？？
在 MySQL 里，有两个“视图”的概念：
作用是事务执行期间用来定义 “我能看到什么数据” 。
一致性视图：
这样，对于当前事务的启动瞬间来说，一个数据版本的 row trx_id，有以下几种可能：
所以这就是 为什么
系统里面随后发生的更新 就跟这个事务看到的内容无关了 而是去看版本
InnoDB 利用了“所有数据都有多个版本”的这个特性，实现了“秒级创建快照”的能力。
更新数据都是先读后写的，而这个读，只能读当前的值，称为“当前读”（current read）。
读提交的逻辑和可重复读的逻辑类似，它们最主要的区别是：
InnoDB 的行数据有多个版本，每个数据版本有自己的 row trx_id，每个事务或者语句有自己的一致性视图。普通查询语句是一致性读，一致性读会根据 row trx_id 和一致性视图确定数据版本的可见性。
而当前读，总是读取已经提交完成的最新版本。
基础篇发布完毕 稍后 会更新 实践篇