MySQL实战45讲（01--05）-笔记
MySQL复习
管理员启动
mysql服务的启动和停止
-
mysql> net stop mysql
-
mysql> net start mysql
登陆mysql
- mysql> 键入命令mysql -u root -p， 回车后提示你输入密码，然后回车即可
01 | 基础架构：一条SQL查询语句是如何执行的？
MySQL 的基本架构示意图：
大体来说，MySQL 可以分为 Server 层和存储引擎层两部分。
连接器
连接器负责跟客户端建立连接、获取权限、维持和管理连接。
mysql -u root -p
虽然密码也可以直接跟在 -p 后面写在命令行中，但这样可能会导致你的密码泄露。
在完成经典的 TCP 握手后，连接器就要开始认证你的身份，
如果用户名密码认证通过，连接器会到权限表里面查出你拥有的权限。
之后，这个连接里面的权限判断逻辑，都将依赖于此时读到的权限。
这就意味着，一个用户成功建立连接后，即使你用管理员账号对这个用户的权限做了修改，也不
会影响已经存在连接的权限。
修改完成后，只有再新建的连接才会使用新的权限设置。
连接完成后，如果你没有后续的动作，这个连接就处于空闲状态，你可以 show processlist; 看到一个sleep。
客户端如果太长时间没动静，连接器就会自动将它断开。这个时间是由参数 wait_timeout 控制的，默认值是 8 小时。
如果在连接被断开之后，客户端再次发送请求的话，就会收到一个错误提醒： Lost connection to MySQL server during query。这时候如果你要继续，就需要重连，然后再执行请求了。
数据库里面，长连接是指连接成功后，如果客户端持续有请求，则一直使用同一个连接。
短连接则是指每次执行完很少的几次查询就断开连接，下次查询再重新建立一个。
全部使用长连接后，有些时候 MySQL 占用内存涨得特别快，
这是因为MySQL 在 执行过程中 临时使用的内存 是管理在 连接对象里面的。
这些资源会在连接断开的时候才释放。所以如果长连接累积下来，可能导致内存占用太大，被系统强行杀掉（OOM），从现象看就是 MySQL 异常重启了。
怎么解决这个问题呢？你可以考虑以下两种方案。
- 定期断开长连接。使用一段时间，或者程序里面判断执行过一个占用内存的大查询后，断开
连接，之后要查询再重连。 - 如果你用的是 MySQL 5.7 或更新版本，可以在每次执行一个比较大的操作后，通过执行
mysql_reset_connection 来重新初始化连接资源。这个过程不需要重连和重新做权限验
证，但是会将连接恢复到刚刚创建完时的状态。
查询缓存
MySQL 拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句。
之前执行过的语句及其结果可能会以 key-value 对的形式，被直接缓存在内存中。
| key | 查询的语句 |
| value | 查询的结果 |
如果你的查询能够直接在这个缓存中找到 key，那么这个 value 就会被直接返回给客户端。
如果语句不在查询缓存中，就会继续后面的执行阶段。
执行完成后，执行结果会被存入查询缓存中。
但是大多数情况下我会建议你不要使用查询缓存，为什么呢？因为查询缓存往往弊大于利。
查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。
对于更新压力大的数据库来说，查询缓存的命中率会非常低。除非你的业务就是有一张静态表，很长时间才会更新一次。
需要注意的是，MySQL 8.0 版本直接将查询缓存的整块功能删掉了，也就是说 8.0 开始彻底没
有这个功能了。
分析器
有兴趣的同学可以去看看《编译原理》
优化器
优化器阶段完成后，这个语句的执行方案就确定下来了，然后进入执行器阶段。
执行器
开始执行的时候，要先判断一下你对这个表 T 有没有执行查询的权限，如果没有，就会返回没有权限的错误，
如果有权限，就打开表继续执行。打开表的时候，优化器就会根据表的引擎定义，去使用这个引擎提供的接口。
例如：
mysql> select * from T where ID=10;
比如我们这个例子中的表 T 中，ID 字段没有索引，那么执行器的执行流程是这样的：
1. 调用 InnoDB 引擎接口取这个表的第一行，判断 ID 值是不是 10，如果不是则跳过，如果
是则将这行存在结果集中；
2. 调用引擎接口取“下一行”，重复相同的判断逻辑，直到取到这个表的最后一行。
3. 执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端。
至此，这个语句就执行完成了。
你会在数据库的慢查询日志中看到一个 rows_examined 的字段，表示这个语句执行过程中扫描
了多少行。这个值就是在执行器每次调用引擎获取数据行的时候累加的。
在有些场景下，执行器调用一次，在引擎内部则扫描了多行，因此引擎扫描行数跟rows_examined 并不是完全相同的。
02 | 日志系统：一条SQL更新语句是如何执行的？
一条更新语句的执行流程又是怎样的呢？
与查询流程不一样的是，更新流程还涉及两个重要的日志模块，它们正是我们今天要讨论的主角：redo log（重做日志）和 binlog（归档日志）
粉板和账本配合的整个过程，其实就是 MySQL 里经常说到的 WAL 技术，WAL 的全称是Write-Ahead Logging，它的关键点就是先写日志，再写磁盘，也就是先写粉板，等不忙的时候再写账本。
重要的日志模块：redo log
具体来说，当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log（粉板）里面，并更新内存，这个时候更新就算完成了。
同时，InnoDB 引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做。
如下面这个图所示：
| wirte pos | 当前记录的位置，一边写一边后移 |
| checkpoint | 当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。 |
write pos 和 checkpoint 之间的是“粉板”上还空着的部分，可以用来记录新的操作。如果
write pos 追上 checkpoint，表示“粉板”满了，这时候不能再执行新的更新，得停下来先擦
掉一些记录，把 checkpoint 推进一下。
有了 redo log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，
这个能力称为crash-safe。
重要的日志模块：binlog
上面我们聊到的粉板 redolog 是 InnoDB 引擎特有的日志，而 Server 层也有自己的日志，称为 binlog（归档日志）。
我想你肯定会问，为什么会有两份日志呢？
因为最开始 MySQL 里并没有 InnoDB 引擎。MySQL 自带的引擎是 MyISAM，
但是 MyISAM没有 crash-safe 的能力，binlog 日志只能用于归档。
而 InnoDB 是另一个公司以插件形式引入
MySQL 的，既然只依靠 binlog 是没有 crash-safe 能力的，所以 InnoDB 使用另外一套日志系统——也就是 redo log 来实现 crash-safe 能力。
这两种日志有以下三点不同。
- redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可
以使用。 - redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，
记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。 - redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指
binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
将 redo log 的写入拆成了两个步骤：prepare和 commit，这就是"两阶段提交"。
两阶段提交
如果不使用“两阶段提交”，那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致。
当你需要扩容的时候，也就是需要再多搭建一些备库来增加系统的读能力的时候，现在常见的做法也是用全量备份加上应用 binlog来实现的，这个“不一致”就会导致你的线上出现主从数据库不一致的情况。
简单说，redo log 和 binlog 都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态保持逻辑上的一致。
小结
redo log 用于保证 crash-safe 能力。innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候，表示每次事务的 redo log 都直接持久化到磁盘。这个参数我建议你设置成 1，这样可以保证 MySQL 异常重启之后数据不丢失。
sync_binlog 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。这个参数我也建议你设置成 1，这样可以保证 MySQL 异常重启之后 binlog 不丢失。
03 | 事务隔离：为什么你改了我还看不见？
简单来说，事务就是要保证一组数据库操作，要么全部成功，要么全部失败。在 MySQL 中，事务支持是在引擎层实现的。
隔离性与隔离级别
在谈隔离级别之前，你首先要知道，你隔离得越严实，效率就会越低。因此很多时候，我们都要在二者之间寻找一个平衡点。SQL 标准的事务隔离级别包括：
在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。
| 读未提交 | 一个事务还没提交时，它做的变更就能被别的事务看到 | 直接返回记录上的最新值，没有视图概念 |
| 读提交 | 一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的 | 这个视图是在每个 SQL 语句开始执行的时候创建的 |
| 可重复读 | 未提交变更对其他事务是不可见的 | 这个视图是在事务启动时创建的，整个事务存在期间都用这个视图 |
| 串行化 | 顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。 | 直接用加锁的方式来避免并行访问 |
例子背景：
| 隔离级别 | V1 | V2 | V3 |
|---|---|---|---|
| 读未提交 | 2 | 2 | 2 |
| 读提交 | 1 | 2 | 2 |
| 可重复读 | 1 | 1 | 2 |
| 串行化 | 1 | 1 | 2 |
Oracle 数据库的默认隔离级别其实就是“读提交”，因此对于一些从 Oracle 迁移到 MySQL 的应用要配置：
show variables like 'transaction_isolation';
//将启动参数 transaction-isolation 的值设置成 READ-COMMITTED。你可以用show variables 来查看当前的值。
事务隔离的实现
在 MySQL 中，实际上每条记录在更新的时候都会同时记录一条回滚操作。记录上的最新值，通过回滚操作，都可以得到前一个状态的值。
什么时候才不需要了呢？就是当系统里没有比这个回滚日志更早的 read-view 的时候。
基于上面的说明，就知道为什么建议你尽量不要使用长事务。
在 MySQL 5.5 及以前的版本，回滚日志是跟数据字典一起放在 ibdata 文件里的，即使长事务
最终提交，回滚段被清理，文件也不会变小。
事务的启动方式
MySQL 的事务启动方式有以下几种：
| 显式启动事务语句 | begin 或 start transaction。配套的提交语句是 commit，回滚语句是 rollback |
| set autocommit=0，这个命令会将这个线程的自动提交关掉 | 意味着如果你只执行一个select 语句，这个事务就启动了，而且并不会自动提交。这个事务持续存在直到你主动执行commit 或 rollback 语句，或者断开连接。 |
建议你总是使用 set autocommit=1, 通过显式语句的方式来启动事务。
在 autocommit 为 1 的情况下，用 begin 显式启动的事务，如果执行 commit 则提交事务。
如果执行 commit work and chain，则是提交事务并自动启动下一个事务，这样也省去了再次执行 begin 语句的开销。
同时带来的好处是从程序开发的角度明确地知道每个语句是否处于事务中。
04 | 深入浅出索引（上）
对于数据库的表而言，索引其实就是它的“目录”
可以用于提高读写效率的数据结构很多，这里我先给你介绍三种常见、也比较简单的数据结构，它们分别是哈希表、有序数组和搜索树。
哈希表这种结构适用于只有等值查询的场景，比如 Memcached 及其他一些 NoSQL 引擎。
而有序数组在等值查询和范围查询场景中的性能就都非常优秀，有序数组索引只适用于静态存储引擎。
为了让一个查询尽量少地读磁盘，就必须让查询过程访问尽量少的数据块。那么，我们就不应该使用二叉树，而是要使用“N 叉”树。这里，“N 叉”树中的“N”取决于数据块的大小。
以 InnoDB 的一个整数字段索引为例，这个 N 差不多是 1200。这棵树高是 4 的时候，就可以存 1200 的 3 次方个值，这已经 17 亿了。考虑到树根的数据块总是在内存中的，一个 10 亿行的表上一个整数字段的索引，查找一个值最多只需要访问 3 次磁盘。其实，树的第二层也有很大概率在内存中，那么访问磁盘的平均次数就更少了。
N 叉树由于在读写上的性能优点，以及适配磁盘的访问模式，已经被广泛应用在数据库引擎中了。
数据库技术发展到今天，跳表、LSM 树等数据结构也被用于引擎设计中…………
InnoDB 的索引模型
InnoDB 使用了 B+ 树索引模型，每一个索引在 InnoDB 里面对应一棵 B+ 树。
举例说明：
mysql> create table T(
id int primary key,
k int not null,
name varchar(16),
index (k))engine=InnoDB;
R1~R5 的 (ID,k) 值分别为 (100,1)、(200,2)、(300,3)、(500,5) 和 (600,6)，两棵树的示例示意图如下：
从图中不难看出，根据叶子节点的内容，索引类型分为主键索引和非主键索引。
主键索引的叶子节点存的是整行数据。在 InnoDB 里，主键索引也被称为聚簇索引（clustered index）。
非主键索引的叶子节点内容是主键的值。在 InnoDB 里，非主键索引也被称为二级索引（secondary index）。
根据上面的索引结构说明，我们来讨论一个问题：基于主键索引和普通索引的查询有什么区别？
如果语句是 select * from T where ID=500，即主键查询方式，则只需要搜索 ID 这棵 B+树；
如果语句是 select * from T where k=5，即普通索引查询方式，则需要先搜索 k 索引树，得到 ID 的值为 500，再到 ID 索引树搜索一次。这个过程称为回表。
也就是说，基于非主键索引的查询需要多扫描一棵索引树。因此，我们在应用中应该尽量使用主键查询。
索引维护
由于 InnoDB 是索引组织表，一般情况下我会建议你创建一个自增主键，这样非主键索引占用的空间最小。但事无绝对。
显然，主键长度越小，普通索引的叶子节点就越小，普通索引占用的空间也就越小。
所以，从性能和存储空间方面考量，自增主键往往是更合理的选择。
05 | 深入浅出索引（下）
例子：
select * from T where k between 3 and 5
mysql> create table T (
ID int primary key,
k int NOT NULL DEFAULT 0,
s varchar(16) NOT NULL DEFAULT '',
index k(k))
engine=InnoDB;
insert into T values(100,1, 'aa'),(200,2,'bb'),(300,3,'cc'),(500,5,'ee'),(600,6,'ff'),(700,7,'gg');
SQL 查询语句的执行流程：
1. 在 k 索引树上找到 k=3 的记录，取得 ID = 300；
2. 再到 ID 索引树查到 ID=300 对应的 R3；
3. 在 k 索引树取下一个值 k=5，取得 ID=500；
4. 再回到 ID 索引树查到 ID=500 对应的 R4；
5. 在 k 索引树取下一个值 k=6，不满足条件，循环结束。
在这个过程中，回到主键索引树搜索的过程，我们称为回表。
覆盖索引
执行上面的语句的时候，ID值已经在K索引树上面了，所以可以不回表。
最左前缀原则
B+ 树这种索引结构，可以利用索引的“最左前缀”，来定位记录。
例如这个表：
用（name，age）这个联合索引来分析，SQL 语句的条件是"where name like ‘张 %’"，可以快速定位。
可以看到，不只是索引的全部定义，只要满足最左前缀，就可以利用索引来加速检索。
评估标准：索引的复用能力
- 如果通过调整顺序，可以少维护一个索引，那么这个顺序往往就是需要优先考虑采用的。
- 空间
索引下推
index condition pushdown，可以在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数。
例如：检索出表中“名字第一个字是张，而且年龄是 10 岁的所有男孩”
每一个虚线箭头表示回表一次。
区别是，InnoDB 在 (name,age) 索引内部就判断了 age 是否等于 10，对于不等于 10 的记录，直接判断并跳过。
