< div style = "color:#16b0ff;font-size:50px;font-weight: 900;text-shadow: 5px 5px 10px var(--theme-color);font-family: 'Comic Sans MS';" > Database< / div >
< span style = "color:#16b0ff;font-size:20px;font-weight: 900;font-family: 'Comic Sans MS';" > Introduction</ span > ：收纳技术相关的数据库知识 `事务` 、`索引`、`锁`、`SQL优化` 等总结！
[TOC]
# 数据库范式
- **1NF**：所有字段仅包含单值（即单个字段不可在分割使用）
- **2NF**：非键字段必须全完依赖于主键（不能是主键的部分）
- **3NF**：非键字段不能依赖于非键字段（禁止传递依赖）
- **BCNF**：并且主属性不依赖于主属性
- **第四范式（ ）
- **第五范式（ ）
> 四种范式之间的关系：
>
> 1NF→2NF：
>
> 2NF→3NF：
>
> 3NF→BCNF：
## 第一范式(1NF)
**列都是不可再分**。即实体中的某个属性有多个值时，必须拆分为不同的属性。例如：
**用户信息表**
| 编号 | 姓名 | 年龄 | 地址 |
| ---- | ---- | ---- | ---------------------------- |
| 1 | 小王 | 23 | 浙江省杭州市拱墅区湖州街51号 |
当实际需求对地址没有特定的要求下，这个用户信息表的每一列都是不可分割的。但是当实际需求对省份或者城市有特别要求时，这个用户信息表中的地址就是可以分割的，改为：
**用户信息表**
| 编号 | 姓名 | 年龄 | 省份 | 城市 | 详细地址 |
| ---- | ---- | ---- | ------ | ------ | ---------------- |
| 1 | 小王 | 23 | 浙江省 | 杭州市 | 拱墅区湖州街51号 |
**好处**
- 表结构相对清晰
- 易于查询
## 第二范式(2NF)
**每个表只描述一件事情**。满足第一范式（ 1NF） ， ， （ ） ， ： ， ，
**学生课程表**
| 学生编号 | 课程编号 | 学生名称 | 课程名称 | 所在班级 | 班主任 |
| -------- | -------- | -------- | ---------- | --------- | ------ |
| S1 | C1 | 小王 | 计算机导论 | 计算机3班 | 陈老师 |
| S1 | C2 | 小王 | 数据结构 | 计算机3班 | 陈老师 |
| S2 | C1 | 小马 | 计算机导论 | 软件1班 | 李老师 |
将学生编号和课程编号作为主键，能确定唯一一条数据，但是学生名称只跟学生编号有关，跟课程编号无关，即不满足完全函数依赖，改为：
**学生表**
| 学生编号 | 学生名称 | 所在班级 | 班主任 |
| -------- | -------- | --------- | ------ |
| S1 | 小王 | 计算机3班 | 陈老师 |
| S2 | 小马 | 软件1班 | 李老师 |
**课程表**
| 课程编号 | 课程名称 |
| -------- | ---------- |
| C1 | 计算机导论 |
| C2 | 数据结构 |
**学生课程关系表**
| 学生编号 | 课程编号 |
| -------- | -------- |
| S1 | C1 |
| S1 | C2 |
| S2 | C1 |
**好处**
- 相对节约空间，当学生表和课程表属性越多，效果越明显
- 解决插入异常，当新增一门课程时，原表因为没有学生选课，导致无法插入数据
- 解决更新繁琐，当更改一门课程名称时，原表要更改多条数据
- 解决删除异常，当学生学完一门课，原表若要清空学生上课信息，课程编号与课程名称的关系可能会丢失
## 第三范式(3NF)
**不存在对非主键列的传递依赖**。满足第二范式（ 2NF） ， （ ） ：
**学生表**
| 学生编号 | 学生名称 | 班级编号 | 班级名字 |
| -------- | -------- | -------- | --------- |
| S1 | 小王 | 001 | 计算机1班 |
| S2 | 小马 | 003 | 计算机3班 |
学生编号作为主键满足第二范式（ ）
**学生表**
| 学生编号 | 学生名称 | 班级编号 |
| -------- | -------- | -------- |
| S1 | 小王 | 001 |
| S2 | 小马 | 003 |
**班级表**
| 班级编号 | 班级名称 |
| -------- | --------- |
| 001 | 计算机1班 |
| 003 | 计算机3班 |
**好处**
- 相对节约空间
- 解决更新繁琐
- 解决插入异常，当班级分配了老师，还没分配学生的时候，原表将不可插入数据
- 解决删除异常，当学生毕业后，若要清空学生信息，班级和老师的关系可能会丢失
## 巴斯-科德范式（ ）
在3NF基础上，
**配件表**
| 仓库号 | 配件号 | 职工号 | 配件数量 |
| ------ | ------ | ------ | -------- |
| W1 | P1 | E1 | 10 |
| W1 | P2 | E1 | 10 |
| W2 | P1 | E2 | 20 |
有以下约束：
- 一个仓库有多个职工
- 一个职工只在一个仓库
- 一种配件可以放多个仓库
- 一个仓库，一个职工管理多个配件，一种配件由唯一一个职工管理
由此，将（仓库号，配件号）作为主键，满足 3NF， （ ， ）
**仓库表**
| 仓库号 | 职工号 |
| ------ | ------ |
| W1 | E1 |
| W2 | E2 |
**工作表**
| 职工号 | 配件号 | 配件数量 |
| ------ | ------ | -------- |
| E1 | P1 | 10 |
| E1 | P2 | 10 |
| E2 | P1 | 20 |
**好处**
- 解决一些冗余和一些异常情况
**不足**
- 丢失一些函数依赖，如丢失（仓库号，配件号）⇒⇒ 职工号，无法通过单表来确定一个职工号
## 第四范式（ ）
在满足第三范式（ ） ，
当一个表中非主属性相互独立时（即在 3NF 基础上），这些非主属性不应该有`多值`。即表中不能包含一个实体的两个或多个互相独立的多值因子。例如：
**客户联系方式**
| 客户编号 | 固定电话 | 移动电话 |
| -------- | -------- | -------- |
| 10 | 88-123 | 151 |
| 10 | 80-123 | 183 |
一个用户拥有多个固定电话和移动电话，给表的维护带来很多麻烦。比如增加一个固定电话，那么移动电话这一栏就较难维护，改为：
**客户电话表**
| 客户编号 | 电话号码 | 电话类型 |
| -------- | -------- | -------- |
| 10 | 88-123 | 固定电话 |
| 10 | 80-123 | 固定电话 |
| 10 | 151 | 移动电话 |
| 10 | 183 | 移动电话 |
**好处**
- 解决一些异常，使表结构更加合理
## 第五范式（ ）
在关系模式 R 中，每一个`连接依赖`均有 R 的`候选码`所隐含。即连接时，所连接的属性都是候选码，例如：
**销售表**
| 销售人员 | 供应商 | 产品 |
| -------- | ------ | ---- |
| S1 | V1 | P1 |
| S2 | V2 | P2 |
| S1 | V1 | P1 |
| S2 | V2 | P2 |
要想找到某一条数据，必须以（销售人员，供应商，产品）为主键，改为：
**销售人员_供应商表**
| 销售人员 | 供应商 |
| -------- | ------ |
| S1 | V1 |
| S2 | V2 |
**销售人员_产品表**
| 销售人员 | 产品 |
| -------- | ---- |
| S1 | P1 |
| S2 | P2 |
**供应商_产品表**
| 供应商 | 产品 |
| ------ | ---- |
| V1 | P1 |
| V2 | P2 |
**好处**
- 解决某些异常操作
# 连接方式
## 内连接（ ）
INNER JOIN 一般被译作内连接。内连接查询能将左表（表 A） （ ）
**文氏图**
.png)
**示例查询**
```mysql
SELECT A.PK AS A_PK, B.PK AS B_PK,A.Value AS A_Value, B.Value AS B_Value
FROM Table_A A
INNER JOIN Table_B B
ON A.PK = B.PK;
```
**查询结果**
```mysql
+------+------+---------+---------+
| A_PK | B_PK | A_Value | B_Value |
+------+------+---------+---------+
| 1 | 1 | both ab | both ab |
+------+------+---------+---------+
1 row in set (0.00 sec)
```
**注意**： ， ，
## 左连接（ ）
LEFT JOIN 一般被译作左连接，也写作 LEFT OUTER JOIN。左连接查询会返回左表（ ） ， （ ）
**文氏图**
.png)
**示例查询**
```mysql
SELECT A.PK AS A_PK, B.PK AS B_PK,A.Value AS A_Value, B.Value AS B_Value
FROM Table_A A
LEFT JOIN Table_B B
ON A.PK = B.PK;
```
**查询结果**
```mysql
+------+------+---------+---------+
| A_PK | B_PK | A_Value | B_Value |
+------+------+---------+---------+
| 1 | 1 | both ab | both ba |
| 2 | NULL | only a | NULL |
+------+------+---------+---------+
2 rows in set (0.00 sec)
```
## 右连接（ ）
RIGHT JOIN 一般被译作右连接，也写作 RIGHT OUTER JOIN。右连接查询会返回右表（ ） ， （ ）
**文氏图**
.png)
**示例查询**
```mysql
SELECT A.PK AS A_PK, B.PK AS B_PK,A.Value AS A_Value, B.Value AS B_Value
FROM Table_A A
RIGHT JOIN Table_B B
ON A.PK = B.PK;
```
**查询结果**
```mysql
+------+------+---------+---------+
| A_PK | B_PK | A_Value | B_Value |
+------+------+---------+---------+
| 1 | 1 | both ab | both ba |
| NULL | 3 | NULL | only b |
+------+------+---------+---------+
2 rows in set (0.00 sec)
```
## 全连接（ ）
FULL JOIN 一般被译作外连接、全连接，实际查询语句中可以写作 FULL OUTER JOIN 或 FULL JOIN。外连接查询能返回左右表里的所有记录， （ ）
**文氏图**
.png)
**示例查询**
```mysql
SELECT A.PK AS A_PK, B.PK AS B_PK,A.Value AS A_Value, B.Value AS B_Value
FROM Table_A A
FULL OUTER JOIN Table_B B
ON A.PK = B.PK;
```
**查询结果**
```mysql
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FULL OUTER JOIN Table_B B
ON A.PK = B.PK' at line 4
```
注意：我当前示例使用的 MySQL 不支持FULL OUTER JOIN。应当返回的结果（ ） ：
```mysql
mysql> SELECT *
-> FROM Table_A
-> LEFT JOIN Table_B
-> ON Table_A.PK = Table_B.PK
-> UNION ALL
-> SELECT *
-> FROM Table_A
-> RIGHT JOIN Table_B
-> ON Table_A.PK = Table_B.PK
-> WHERE Table_A.PK IS NULL;
+------+---------+------+---------+
| PK | Value | PK | Value |
+------+---------+------+---------+
| 1 | both ab | 1 | both ba |
| 2 | only a | NULL | NULL |
| NULL | NULL | 3 | only b |
+------+---------+------+---------+
3 rows in set (0.00 sec)
```
**SQL常见缩影**
## LEFT JOIN EXCLUDING INNER JOIN
返回左表有但右表没有关联数据的记录集。
**文氏图**
**示例查询**
```mysql
SELECT A.PK AS A_PK, B.PK AS B_PK,A.Value AS A_Value, B.Value AS B_Value
FROM Table_A A
LEFT JOIN Table_B B
ON A.PK = B.PK
WHERE B.PK IS NULL;
```
**查询结果**
```mysql
+------+------+---------+---------+
| A_PK | B_PK | A_Value | B_Value |
+------+------+---------+---------+
| 2 | NULL | only a | NULL |
+------+------+---------+---------+
1 row in set (0.01 sec)
```
## RIGHT JOIN EXCLUDING INNER JOIN
返回右表有但左表没有关联数据的记录集。
**文氏图**
**示例查询**
```mysql
SELECT A.PK AS A_PK, B.PK AS B_PK,A.Value AS A_Value, B.Value AS B_Value
FROM Table_A A
RIGHT JOIN Table_B B
ON A.PK = B.PK
WHERE A.PK IS NULL;
```
**查询结果**
```mysql
+------+------+---------+---------+
| A_PK | B_PK | A_Value | B_Value |
+------+------+---------+---------+
| NULL | 3 | NULL | only b |
+------+------+---------+---------+
1 row in set (0.00 sec)
```
## FULL JOIN EXCLUDING INNER JOIN
返回左表和右表里没有相互关联的记录集。
**文氏图**
**示例查询**
```mysql
SELECT A.PK AS A_PK, B.PK AS B_PK,A.Value AS A_Value, B.Value AS B_Value
FROM Table_A A
FULL OUTER JOIN Table_B B
ON A.PK = B.PK
WHERE A.PK IS NULL
OR B.PK IS NULL;
```
因为使用到了 FULL OUTER JOIN，
```mysql
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FULL OUTER JOIN Table_B B
ON A.PK = B.PK
WHERE A.PK IS NULL
OR B.PK IS NULL' at line 4
```
应当返回的结果（用 UNION 模拟）：
```mysql
mysql> SELECT *
-> FROM Table_A
-> LEFT JOIN Table_B
-> ON Table_A.PK = Table_B.PK
-> WHERE Table_B.PK IS NULL
-> UNION ALL
-> SELECT *
-> FROM Table_A
-> RIGHT JOIN Table_B
-> ON Table_A.PK = Table_B.PK
-> WHERE Table_A.PK IS NULL;
+------+--------+------+--------+
| PK | Value | PK | Value |
+------+--------+------+--------+
| 2 | only a | NULL | NULL |
| NULL | NULL | 3 | only b |
+------+--------+------+--------+
2 rows in set (0.00 sec)
```
**SQL所有JOIN**
## CROSS JOIN
返回左表与右表之间符合条件的记录的迪卡尔集。
**图示**
**示例查询**
```mysql
SELECT A.PK AS A_PK, B.PK AS B_PK,A.Value AS A_Value, B.Value AS B_Value
FROM Table_A A
CROSS JOIN Table_B B;
```
**查询结果**
```mysql
+------+------+---------+---------+
| A_PK | B_PK | A_Value | B_Value |
+------+------+---------+---------+
| 1 | 1 | both ab | both ba |
| 2 | 1 | only a | both ba |
| 1 | 3 | both ab | only b |
| 2 | 3 | only a | only b |
+------+------+---------+---------+
4 rows in set (0.00 sec)
```
上面讲过的几种 JOIN 查询的结果都可以用 CROSS JOIN 加条件模拟出来，比如 INNER JOIN 对应 CROSS JOIN ... WHERE A.PK = B.PK。
## SELF JOIN
返回表与自己连接后符合条件的记录，一般用在表里有一个字段是用主键作为外键的情况。比如 Table_C 的结构与数据如下：
```mysql
+--------+----------+-------------+
| EMP_ID | EMP_NAME | EMP_SUPV_ID |
+--------+----------+-------------+
| 1001 | Ma | NULL |
| 1002 | Zhuang | 1001 |
+--------+----------+-------------+
2 rows in set (0.00 sec)
```
EMP_ID 字段表示员工 ID， ，
**示例查询**
现在我们想查询所有有主管的员工及其对应的主管 ID 和姓名，就可以用 SELF JOIN 来实现。
```mysql
SELECT A.EMP_ID AS EMP_ID, A.EMP_NAME AS EMP_NAME,
B.EMP_ID AS EMP_SUPV_ID, B.EMP_NAME AS EMP_SUPV_NAME
FROM Table_C A, Table_C B
WHERE A.EMP_SUPV_ID = B.EMP_ID;
```
**查询结果**
```mysql
+--------+----------+-------------+---------------+
| EMP_ID | EMP_NAME | EMP_SUPV_ID | EMP_SUPV_NAME |
+--------+----------+-------------+---------------+
| 1002 | Zhuang | 1001 | Ma |
+--------+----------+-------------+---------------+
1 row in set (0.00 sec)
```
**补充说明**
- 文中的图使用 Keynote 绘制
- 个人的体会是 SQL 里的 JOIN 查询与数学里的求交集、并集等很像； ，
- MySQL 不支持 FULL OUTER JOIN，
# 数据库锁
从粒度上来说就是**表锁、页锁、行锁**。表锁有意向共享锁、意向排他锁、自增锁等。行锁是在引擎层由各个引擎自己实现的。但并不是所有的引擎都支持行锁，比如 `MyISAM` 引擎就`不支持行锁`。
## 行锁(Record Locks)
在 `InnoDB` 事务中，行锁通过给索引上的索引项加锁来实现。即只有通过索引条件检索数据，`InnoDB` 才使用行级锁，否则将使用表锁。行级锁定同样分为两种类型：`共享锁` 和`排他锁`，以及加锁前需要先获得的 `意向共享锁` 和 `意向排他锁` 。
行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议。
### 共享锁(Shared Locks)
共享锁又称为 `S锁` 或 `读锁` 。若事务T对数据对象A加上 `S锁` ， `只能读A` ； ， ， ，
- `select ... lock in share mode` : 会加`共享锁`
### 排它锁(Exclusive Locks)
排它锁又称为 `X锁` 或 `写锁` 。若事务T对数据对象A加上X锁， ， ， ，
注意：排他锁会阻止其它事务再对其**锁定的数据**加读或写的锁，但是不加锁的就没办法控制了。
- `insert` 、`update`、`delete`、`select ... for update`：会加`排它锁`
## 行锁实现算法
### Record Lock（ ）
单个行记录上的锁，总是会去锁住索引记录。
行锁，顾名思义，是加在`索引行`(是索引行，不是数据行)上的锁。比如：
`select * from user where id=1 and id=10 for update` ，就会在`id=1`和`id=10`的索引行上加Record Lock。
### Gap Lock（ ）
间隙锁，它会锁住两个索引之间的区域。比如：
`select * from user where id>1 and id<10 for update` ，
想一下幻读的原因，其实就是行锁只能锁住行，但新插入记录这个动作，要更新的是记录之间的“`间隙`”。所以加入间隙锁来解决幻读。
### Next-Key Lock（ ）
也叫间隙锁，它是 Record Lock + Gap Lock 形成的一个闭区间锁。比如：
`select * from user where id>=1 and id<=10 for update` ，
这样组合起来就有：行级共享锁，表级共享锁；行级排它锁，表级排它锁。
## MVCC
**MVCC**主要是通过**版本链**和**ReadView**来实现的。在Mysql的InnoDB引擎中，
### 版本链
在InnoDB引擎表中， ：
- `DATA_TRX_ID` ：表示插入或更新该行的最后一个事务的事务标识符，同样删除在内部被视为更新，在该更新中，行中的特殊位被设置为将其标记为已删除。行中会有一个特殊位置来标记删除。
- `DATA_ROLL_PTR` ：存储了一个指针，它指向这条记录的上一个版本的位置，通过它来获得上一个版本的记录信息。
**作用**：解决了读和写的并发执行。
### ReadView
ReadView主要存放的是当前事务操作时， （ ， ）
- **ReadView数据结构**：
- `trx_ids` ： ， ，
- `low_limit_id` ： ，
- `up_limit_id` ： ，
- `creator_trx_id` ：
- **ReadView创建策略**： ， ，
- `可重复读隔离级别` ：事务开启后，第一次查询的时候创建，之后一直不变，直到事务结束
- `读提交隔离级别` ：事务开启后，每一次读取都重新创建
也就是说已提交读隔离级别下的事务在每次查询的开始都会生成一个独立的ReadView， ，
# 事务
**什么叫事务?**
事务是一系列对系统中数据进行访问与更新的操作组成的一个程序逻辑单元。即不可分割的许多基础数据库操作。
## 事务特性（ ）
### 原子性（ ）
**事务是最小的执行单位，不允许分割。原子性确保动作要么全部完成，要么完全不起作用。**
原子性是依赖于回滚日志（`undo log`）实现的。当事务对数据库进行修改时，`InnoDB`会生成对应的 `undo log` ；如果事务执行失败或调用了 `rollback` ，导致`事务需要回滚`，便可以利用 `undo log` 中的信息将数据回滚到修改之前的样子。`undo log`属于逻辑日志， ， `undo log` 的内容做与之前相反的工作：
- 对于每个`insert`，回滚时会执行`delete`
- 对于每个 `delete` ，回滚时会执行`insert`
- 对于每个 `update` ，回滚时会执行一个相反的 `update` ，把数据改回去
以`update`操作为例：当事务执行`update`时，其生成的`undo log`中会包含被修改行的主键、修改了哪些列、这些列在修改前后的值等信息，回滚时便可以使用这些信息将数据还原到`update`之前的状态。
### 一致性（ ）
**事务开始前和结束后，数据库的完整性约束没有被破坏**。比如A向B转账， ，
一致性是事务追求的最终目标，原子性、持久性和隔离性其实都是为了保证数据库状态的一致性。当然，都是数据库层面的保障，一致性的实现也需要应用层面进行保障。也就是你的业务，比如购买操作只扣除用户的余额，不减库存，肯定无法保证状态的一致。
### 隔离性（ ）
**并发访问数据库时，一个事务不被其他事务所干扰。**
隔离性是通过 `锁` 和 `MVCC` （多版本并发控制） 实现。InnoDB采用的MVCC实现方式是： ，
### 持久性（ ）
**一个事务被提交之后。对数据库中数据的改变是持久的，即使数据库发生故障。**
`InnnoDB` 有很多 log， `WAL` 技术，`WAL`的全称是`Write-Ahead Logging`，它的关键点就是先写日志，再写磁盘。
**redo log**
当有一条记录要更新时，`InnoDB`引擎就会先把记录写到`redo log`（并更新内存），这个时候更新就算完成了。在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做。`redo log`有两个特点
- 大小固定，循环写
- `crash-safe`
对于`redo log`是有两阶段的：`commit` 和 `prepare` 如果不使用“两阶段提交”，数据库的状态就有可能和用它的日志恢复出来的库的状态不一致。
**Buffer Pool**
InnoDB还提供了缓存，
- 当读取数据时，会先从`Buffer Pool`中读取，如果`Buffer Pool`中没有，
- 当向数据库写入数据时，会首先写入`Buffer Pool`，
Buffer Pool 的使用大大提高了读写数据的效率，但是也带了新的问题：如果`MySQL`宕机，而此时 `Buffer Pool` 中修改的数据还没有刷新到磁盘，就会导致数据的丢失，事务的持久性无法保证。
**所以加入了 redo log。** 当数据修改时，除了修改`Buffer Pool`中的数据，还会在`redo log`记录这次操作。当事务提交时，会调用`fsync`接口对`redo log`进行刷盘。如果`MySQL`宕机，重启时可以读取`redo log`中的数据，对数据库进行恢复。
`redo log` 采用的是WAL（ ， ， ：
- 刷脏页是随机`IO`，
- 刷脏页以Page为单位， ；
## 隔离级别
数据库事务隔离级别有4种， ：
**事务并发问题**
在事务的并发操作中，不做隔离操作则可能会出现 ** 脏读、不可重复读、幻读** 问题：
- **脏读**： ，
- **不可重复读**： ，
- **幻读**： ， ，
**小结**：不可重复读的和幻读很容易混淆，**不可重复读**侧重于**修改**，
**默认隔离级别**
- Oracle仅有Serializable(串行化)和Read Committed(读已提交)两种隔离方式，默认选择**读已提交**的方式
- MySQL默认为**Repeatable Read（ ）
**数据库中的锁**
- **共享锁（ ） ， ， ， ， ，
- **排它锁（ ） ， ， ，
- **更新锁（ ） ： ， ， ； ， ， ， ， ， ， ， ， ， ， ， ，
**InnoDB存储引擎下**的四种隔离级别发生问题的可能性如下：
| 隔离级别 | 第一类丢失更新 | 第二类丢失更新 | 脏读 | 不可重复读 | 幻读 |
| -------------------------- | -------------- | -------------- | -------- | ---------- | -------- |
| Read Uncommitted(读未提交) | 不可能 | ** 可能** | ** 可能** | ** 可能** | ** 可能** |
| Read Committed(读已提交) | 不可能 | ** 可能** | 不可能 | ** 可能** | ** 可能** |
| Repeatable Read(可重复读) | 不可能 | 不可能 | 不可能 | 不可能 | ** 可能** |
| Serializable(串行化) | 不可能 | 不可能 | 不可能 | 不可能 | 不可能 |
### Read Uncommitted(读未提交)
**即读取到了其它事务未提交的内容**。在该隔离级别，**所有事务都可以看到其他未提交事务的执行结果**。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为**脏读（ ）
**特点**：最低级别，任何情况都无法保证
**读未提交的数据库锁情况**
- 读取数据：**未加锁**
- 写入数据：**只对数据增加行级共享锁**
### Read Committed(读已提交)
**即读取到了其它事务已提交的内容**。一个事务只能看见已经提交事务所做的改变。这种隔离级别也支持所谓的**不可重复读（ ） ， ，
**特点**：避免脏读
**读已提交的数据库锁情况**
- 读取数据：**加行级共享锁（读到时才加锁），读完后立即释放**
- 写入数据：**在更新时的瞬间对其加行级排它锁，直到事务结束才释放**
**Read Committed隔离级别下的加锁分析**
隔离级别的实现与锁机制密不可分， ， ：
- **共享锁(S Lock)**： ， ， ， ， ， ，
- **排他锁(X Lock)**: 又称为写锁， ， ， ，
**注意**：
### Repeatable Read(可重复读)
**它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行**。但会导致**幻读 （ ）
**幻读** 是户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当该用户再读取该范围的数据行时，会发现有新的“幻影” 行。
**特点**：
**可重复读的数据库锁情况**
- 读取数据：**开始读取的瞬间对其增加行级共享锁，直到事务结束才释放**
- 写入数据：**开始更新的瞬间对其增加行级排他锁，直到事务结束才释放**
### Serializable(可串行化)
**指一个事务在执行过程中完全看不到其他事务对数据库所做的更新**。当两个事务同时操作数据库中相同数据时，如果第一个事务已经在访问该数据，第二个事务只能停下来等待，必须等到第一个事务结束后才能恢复运行。因此这两个事务实际上是串行化方式运行。
**特点**：避免脏读、不可重复读、幻读
**可序列化的数据库锁情况**
- 读取数据：**先对其加表级共享锁 ，直到事务结束才释放**
- 写入数据：**先对其加表级排他锁 ，直到事务结束才释放**
## SpringBoot Transaction
查看 `mysql` 事务隔离级别：`show variables like 'tx_iso%';`。
### 实现方式
在Spring中事务有两种实现方式：
- **编程式事务管理**：
- **声明式事务管理**：
### 提交方式
**默认情况下，数据库处于自动提交模式**。每一条语句处于一个单独的事务中，在这条语句执行完毕时，如果执行成功则隐式的提交事务，如果执行失败则隐式的回滚事务。
对于正常的事务管理， ， ， ， ， ， `connection.setAutoCommit(false);` ，在执行完之后在进行提交，`connection.commit();` 。
### 事务隔离级别
隔离级别是指若干个并发的事务之间的隔离程度。
```java
@Transactional (isolation = Isolation.READ_UNCOMMITTED)
public void addGoods(){
......
}
```
枚举类Isolation中定义了五种隔离级别：
- `DEFAULT` ：默认值。表示使用底层数据库的默认隔离级别。对大部分数据库而言，通常这值就是**READ_COMMITTED**
- `READ_UNCOMMITTED` ：该隔离级别表示一个事务可以读取另一个事务修改但还没有提交的数据。该级别不能防止脏读，不可重复读和幻读，因此很少使用该隔离级别
- `READ_COMMITTED` ：该隔离级别表示一个事务只能读取另一个事务已经提交的数据。该级别可以防止脏读，这也是大多数情况下的推荐值
- `REPEATABLE_READ` ：该隔离级别表示一个事务在整个过程中可以多次重复执行某个查询，并且每次返回的记录都相同。该级别可以防止脏读和不可重复读
- `SERIALIZABLE` ：所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别
### 事务传播行为
事务的传播性一般用在事务嵌套的场景，如一个事务方法里面调用了另外一个事务方法，那两个方法是各自作为独立的方法提交还是内层事务合并到外层事务一起提交，这就需要事务传播机制配置来确定怎么样执行。
```java
@Transactional (propagation=Propagation.REQUIRED)
public void addGoods(){
......
}
```
枚举类Propagation中定义了七种事务传播机制如下：
- `REQUIRED` （ ）
Spring默认的传播机制， ， ， ， ， ，
- `REQUIRES_NEW` （ ， ）
该事务传播机制是每次都会新开启一个事务，同时把外层事务挂起，当当前事务执行完毕，恢复上层事务的执行。如果外层没有事务，执行当前新开启的事务即可
- `SUPPORTS` （ ）
如果外层有事务，则加入外层事务，如果外层没有事务，则直接使用非事务方式执行。完全依赖外层的事务
- `NOT_SUPPORTED` （ ， ）
该传播机制不支持事务，如果外层存在事务则挂起，执行完当前代码，则恢复外层事务，无论是否异常都不会回滚当前的代码
- `NEVER` （ ）
该传播机制不支持外层事务，即如果外层有事务就抛出异常
- `MANDATORY` （ ）
与NEVER相反， ，
- `NESTED` （ ， ）
该传播机制的特点是可以保存状态保存点，当前事务回滚到某一个点，从而避免所有的嵌套事务都回滚，即各自回滚各自的，如果子事务没有把异常吃掉，基本还是会引起全部回滚的。
### 事务回滚规则
指示spring事务管理器回滚一个事务的推荐方法是在当前事务的上下文内抛出异常。spring事务管理器会捕捉任何未处理的异常，
默认配置下， ， ，
可以明确的配置在抛出那些异常时回滚事务，
### 事务常用配置
- **readOnly**
该属性用于设置当前事务是否为只读事务， ， ， ：
- **rollbackFor**
该属性用于设置需要进行回滚的异常类数组，当方法中抛出指定异常数组中的异常时，则进行事务回滚。例如：指定单一异常类：@Transactional(rollbackFor=RuntimeException.class)指定多个异常类：@Transactional(rollbackFor={RuntimeException.class, Exception.class})
- **rollbackForClassName**
该属性用于设置需要进行回滚的异常类名称数组，当方法中抛出指定异常名称数组中的异常时，则进行事务回滚。例如：指定单一异常类名称@Transactional(rollbackForClassName=”RuntimeException”)指定多个异常类名称：@Transactional(rollbackForClassName={“RuntimeException”,”Exception”})
- **noRollbackFor**
该属性用于设置不需要进行回滚的异常类数组，当方法中抛出指定异常数组中的异常时，不进行事务回滚。例如：指定单一异常类：@Transactional(noRollbackFor=RuntimeException.class)指定多个异常类：@Transactional(noRollbackFor={RuntimeException.class, Exception.class})
- **noRollbackForClassName**
该属性用于设置不需要进行回滚的异常类名称数组，当方法中抛出指定异常名称数组中的异常时，不进行事务回滚。例如：指定单一异常类名称：@Transactional(noRollbackForClassName=”RuntimeException”)指定多个异常类名称：@Transactional(noRollbackForClassName={“RuntimeException”,”Exception”})
- **propagation**
该属性用于设置事务的传播行为。例如：@Transactional(propagation=Propagation.NOT_SUPPORTED,readOnly=true)
- **isolation**
该属性用于设置底层数据库的事务隔离级别，事务隔离级别用于处理多事务并发的情况，通常使用数据库的默认隔离级别即可，基本不需要进行设置
- **timeout**
该属性用于设置事务的超时秒数，默认值为-1表示永不超时
### 事物注意事项
- 要根据实际的需求来决定是否要使用事物，最好是在编码之前就考虑好，不然到以后就难以维护
- 如果使用了事物，请务必进行事物测试，因为很多情况下以为事物是生效的，但是实际上可能未生效
- 事物@Transactional的使用要放再类的**公共(public)方法**中，需要注意的是在 protected、private 方法上使用 @Transactional 注解，它也不会报错(IDEA会有提示)，但事务无效
- 事物@Transactional是不会对该方法里面的子方法生效！ ， ， ， ， ！ ， ， ！ ， ，
- 事物@Transactional由spring控制的时候， ， ， ，
### 失效场景
- **@Transactional 应用在非 public 修饰的方法上**
- **数据库引擎要不支持事务**
- **由于propagation 设置错误，导致注解失效**
- **rollbackFor 设置错误，@Transactional 注解失效**
- **方法之间的互相调用也会导致@Transactional失效**
- **异常被你的 catch“吃了”导致@Transactional失效**
### select for update
`for update` 是一种`行级锁`，又叫`排它锁`。一旦用户对某个行施加了行级加锁，则该用户可以查询也可以更新被加锁的数据行，其它用户只能查询但不能更新被加锁的数据行。
- **修改sql**：在 `select` 的 `sql` 尾部添加 `for update` 。如：`select * from job_info where id = 1 for update;`
- **启用事务**：为 `service` 添加注解 `@Transactional`
**只有当出现如下之一的条件，才会释放共享更新锁：**
1. 执行提交（ ）
2. 退出数据库（ ）
3. 程序停止运行
假设有个表单products ， ，
```mysql
-- 例1: 明确指定主键， ，
SELECT * FROM products WHERE id='3' FOR UPDATE;
-- 例2: 明确指定主键， ，
SELECT * FROM products WHERE id='-1' FOR UPDATE;
-- 例2: 无主键，
SELECT * FROM products WHERE name='Mouse' FOR UPDATE;
-- 例3: 主键不明确，
SELECT * FROM products WHERE id< >'3' FOR UPDATE;
-- 例4: 主键不明确，
SELECT * FROM products WHERE id LIKE '3' FOR UPDATE;
```
**注意**
- FOR UPDATE 仅适用于InnoDB，
- 要测试锁定的状况，
# 数据库
## 存储引擎
InnoDB 和 MyISAM 的比较：
- 事务：
- 并发：
- 外键：
- 备份：
- 崩溃恢复：
- 其它特性：
### InnoDB
- InnoDB 是 MySQL 默认的事务型存储引擎，只要在需要它不支持的特性时，才考虑使用其他存储引擎。
- InnoDB ** 采用 MVCC 来支持高并发**，并且**实现了四个标准隔离级别**(未提交读、提交读、可重复读、可串行化)。其默认级别时可重复读（ ） ， ，
- 主索引时聚簇索引，在索引中保存了数据，从而避免直接读取磁盘，因此对主键查询有很高的性能。
- InnoDB 内部做了很多优化，包括从磁盘读取数据时采用的可预测性读，能够自动在内存中创建 hash 索引以加速读操作的自适应哈希索引，以及能够加速插入操作的插入缓冲区等。
- InnoDB 支持真正的在线热备份，
### MyISAM
- 设计简单，数据以紧密格式存储。对于只读数据，或者表比较小、可以容忍修复操作，则依然可以使用它。
- 提供了大量的特性，包括压缩表、空间数据索引等。
- 不支持事务。
- 不支持行级锁， ， ， ， ， （ ）
- 可以手工或者自动执行检查和修复操作，但是和事务恢复以及崩溃恢复不同，可能导致一些数据丢失，而且修复操作是非常慢的。
- 如果指定了 DELAY_KEY_WRITE 选项，在每次修改执行完成时，不会立即将修改的索引数据写入磁盘，而是会写到内存中的键缓冲区，只有在清理键缓冲区或者关闭表的时候才会将对应的索引块写入磁盘。这种方式可以极大的提升写入性能，但是在数据库或者主机崩溃时会造成索引损坏，需要执行修复操作。
## 锁类型
锁是数据库系统区别于文件系统的一个关键特性。锁机制用于管理对共享资源的并发访问。
**共享锁（ ）
**排他锁（ ）
**意向共享锁（ ）
**意向排他锁**：事务想要获得一张表中某几行的排他锁
## 锁算法
### Record Lock
锁定一个记录上的索引，而不是记录本身。
如果表没有设置索引，
### Gap Lock
锁定索引之间的间隙，但是不包含索引本身。例如当一个事务执行以下语句，其它事务就不能在 t.c 中插入 15。
```sql
SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE;
```
### Next-Key Lock
它是 Record Locks 和 Gap Locks 的结合， ， ： ， ：
```
(-∞, 10]
(10, 11]
(11, 13]
(13, 20]
(20, +∞)
```
在 InnoDB 存储引擎中， ， （ ）
## 锁问题
### 脏读
脏读指的是不同事务下，当前事务可以读取到另外事务未提交的数据。
例如： ，
### 不可重复读
不可重复读指的是同一事务内多次读取同一数据集合，读取到的数据是不一样的情况。
例如： ，
在 InnoDB 存储引擎中：
- `SELECT` ：操作的不可重复读问题通过 MVCC 得到了解决的
- `UPDATE/DELETE` ：操作的不可重复读问题是通过 Record Lock 解决的
- `INSERT` ：操作的不可重复读问题是通过 Next-Key Lock（ ）
### 幻读
幻读是指在同一事务下，连续执行两次同样的 sql 语句可能返回不同的结果，第二次的 sql 语句可能会返回之前不存在的行。幻影读是一种特殊的不可重复读问题。
### 丢失更新
一个事务的更新操作会被另一个事务的更新操作所覆盖。
例如： ， ， ，
这类型问题可以通过给 SELECT 操作加上排他锁来解决，不过这可能会引入性能问题，具体使用要视业务场景而定。
## 数据切分
### 水平切分
水平切分又称为 Sharding， ，
### 垂直切分
垂直切分是将一张表按列分成多个表，通常是按照列的关系密集程度进行切分，也可以利用垂直气氛将经常被使用的列喝不经常被使用的列切分到不同的表中。在数据库的层面使用垂直切分将按数据库中表的密集程度部署到不通的库中，例如将原来电商数据部署库垂直切分称商品数据库、用户数据库等。
### Sharding策略
- 哈希取模：
- 范围：可以是 ID 范围也可以是时间范围
- 映射表：使用单独的一个数据库来存储映射关系
### Sharding存在的问题
- **事务问题**：使用分布式事务来解决，比如 XA 接口
- **连接**：可以将原来的连接分解成多个单表查询，然后在用户程序中进行连接。
- **唯一性**
- 使用全局唯一 ID （ ）
- 为每个分片指定一个 ID 范围
- 分布式 ID 生成器（如 Twitter 的 Snowflake 算法）
## 复制
### 主从复制
主要涉及三个线程：
- **binlog 线程**： （ ）
- **I/O 线程**：负责从主服务器上读取- 二进制日志， （ ）
- **SQL 线程**： ， （ ）
### 读写分离
主服务器处理写操作以及实时性要求比较高的读操作，而从服务器处理读操作。读写分离能提高性能的原因在于：
- 主从服务器负责各自的读和写，极大程度缓解了锁的争用
- 从服务器可以使用 MyISAM，
- 增加冗余，提高可用性
读写分离常用代理方式来实现，代理服务器接收应用层传来的读写请求，然后决定转发到哪个服务器。
## 索引
### 索引的优点
- **大大减少了服务器需要扫描的数据行数**
- **帮助服务器避免进行排序和分组，以及避免创建临时表**（
- **将随机 I/O 变为顺序 I/O**（
# 索引
建立索引的目的是加快对表中记录的查找或排序。索引只是提高效率的一个因素， ， ，
**优点**
- 索引大大减小了服务器需要扫描的数据量
- 索引可以帮助服务器避免排序和临时表
- 索引可以将随机IO变成顺序IO
- 索引对于InnoDB（ ） ，
- 关于InnoDB、索引和锁： （ ） ， （ ）
**缺点**
- 虽然索引大大提高了查询速度， ， ， ，
- 建立索引会占用磁盘空间的索引文件。一般情况这个问题不太严重，但如果你在一个大表上创建了多种组合索引，索引文件的会膨胀很快
- 如果某个数据列包含许多重复的内容，为它建立索引就没有太大的实际效果
- 对于非常小的表，大部分情况下简单的全表扫描更高效
**索引规范**
- 索引的数量要控制
- **单张表** 中索引数量不超过 **5** 个
- **单个索引** 中的字段数不超过 **5** 个（ ， ）
- 对字符串使⽤ ** 前缀索引**，前缀索引长度不超过 **8** 个字符，必要时可添加伪列并建立索引
- 禁止在 ** 更新十分频繁**、**区分度不高** 的属性上建立索引
- 更新会变更B+树，更新频繁的字段建立索引会大大降低数据库性能
- “性别”这种区分度不大的属性，建立索引是没有意义的，其不能有效过滤数据，性能与全表扫描类似
- 不在索引列进行 ** 数学运算** 和 ** 函数运算**
- 建立组合索引：必须 ** 把区分度高的字段放在前面**（能够更加有效的过滤数据）
- 重要的SQL必须被索引， ：
- **UPDATE**、**DELETE** 语句的 **WHERE** 条件列
- **ORDER BY**、**GROUP BY**、**DISTINCT** 的字段
- **多表JOIN** 的字段注意以下（优化准则）
- **区分度最大** 的字段放在前面
- 核⼼SQL优先考虑 ** 覆盖索引**
- 避免 ** 冗余** 和 ** 重复** 索引
- 索引要综合评估数据 ** 密度** 和 ** 分布**以及考虑 ** 查询** 和 ** 更新** 比例
- 索引命名
- 索引名称必须 ** 全部小写**
- 唯一所以必须以 **uniq _ 字段1 _ 字段2** 命名
- 非唯一索引必须以 **idx _ 字段1 _ 字段2** 命名
- 新建的 ** 唯一索引** 必须不能和主键重复
- 索引字段的默认值不能为 **NULL** （ ）
- 反复查看与表相关的SQL， ** 最左前缀** 的特点建立索引
多条件字段重复的语句，要修改语句条件字段的顺序，为其建立一条 ** 联合索引**，减少索引数量
- **优先使用唯一索引**：能使用唯一索引就要使用唯一索引，提高查询效率
- 研发要经常使用 **explain** ， ，
## 索引结构
### 二叉树
**特点**
1. 左子节点值 < 节点值
2. 右子节点值 > 节点值
3. 当数据量非常大时，要查找的数据又非常靠后，和没有索引相比，那么二叉树结构的查询优势将非常明显
**存在问题**
如下图，可以看出，二叉树出现单边增长时，二叉树变成了“链”，这样查找一个数的时候，速度并没有得到很大的优化。
### 红黑树
**特点**
1. 节点是红色或者黑色
2. 根节点是黑色
3. 每个叶子的节点都是黑色的空节点（ ）
4. 每个红色节点的两个子节点都是黑色的
5. 从任意节点到其每个叶子的所有路径都包含相同的黑色节点
**存在的问题**
**红黑树虽然和二叉树相比，一定程度上缓解了单边过长的问题，但是它依旧存储高度问题。**
假设现在数据量有100万， ， ， ， ， ， ，
**思考：针对上面的红黑树结构，我们能否优化一下呢？**
上述红黑树默认一个节点就存了一个 (索引+磁盘地址)，我们设想一个节点存多个 （索引+磁盘地址），这样就可以降低红黑树的高度了。 ** 实际上我们设想的这种结构就是 B-Tree**。
### Hash
**原理**
1. 事先将索引通过 hash算法后得到的hash值(即磁盘文件指针）
2. 在进行查询时， ， ， ，
例如： ， ， ，
**存在问题**
但是hash表索引存在问题， ，
```mysql
select *from t where col1>=6;
```
### B-Tree
**特点**
B-Tree索引能很好解决红黑树中遗留的高度问题， （ ） ， ， ， （ ）
为了描述B-Tree， ， ， ， ； ：
1. d 为大于1的一个正整数，
2. h为一个正整数，
3. key和指针互相间隔，
4. 叶子节点具有相同的深度，叶子节点的指针为空，节点中数据索引(下图中的key)从左往右递增排列
**说明**：下图都是以主键索引为例，至于非主键索引(非聚集索引)，
**分析**
模拟下查找key为29的data的过程：
1. 根据根结点指针读取文件目录的根磁盘块1。【磁盘IO操作第**1次**】
2. 磁盘块1存储17， < 29 < 35 ，因此我们找到指针 p2
3. 根据p2指针，
4. 磁盘块3存储26， < 29 < 30 ，因此我们找到指针 p2
5. 根据p2指针，
6. 磁盘块8中存储28， ，
**存在问题**
1. 比如，下面查询语句，那么不但需要叶子节点>20的值， ， **B-Tree似乎在范围查找没有更简便的方法，
```mysql
select *from t where col1 > 20;
```
2. 深度问题
从图上可以看到， ， ， ， （ ） （ ） ， ， ， ， ，
### B+Tree
**特点**
`B+Tree` 是在`B-Tree`基础上的一种优化， ， ， ， ，
1. 非叶子节点不存储data， ，
2. 叶子节点不存储指针
3. 顺序访问指针，提高区间访问性能
4. 非叶子节点中的索引最终还是会在叶子节点上存储一份，也就是叶子节点会包含非叶子节点上的所有索引
5. 一个父节点，它的**左侧**子节点都**小于**父节点的值，**右侧**的子节点都**大于等于**父节点的值
6. 每一层节点从左往右都是递增排列，无论是数值型还是字符型
**注意**：
****
**剖析**： ， （ ） ， ， < 这类查找问题。
**分析**
假如：**以一个高度为3的B+Tree为例**， ， ？
**首先，**查看MySQL默认一个节点页的大小：
```mysql
SHOW GLOBAL STATUS like 'Innodb_page_size';
```
如下图：
然后， ， ， ， ， ，
1. 第一层最大节点数为： 16k / (8B + 6B) = 1170 (个)
2. 第二层最大节点数也应为：
3. 第三层最大节点数为：
则， * 1170 * 16 = 21902400 ≈ 2千万。所以， ， ， ， （ ， ）
**扩展**
数据库中的B+Tree索引可以分为聚集索引（ ， ） （ ， ） ， ， ， ， ， ，
## 索引类型
### 普通索引
**普通索引（单列索引）**：单列索引是最基本的索引，它没有任何限制。
- 直接创建索引
```mysql
CREATE INDEX index_name ON table_name(col_name);
```
- 修改表结构的方式添加索引
```mysql
ALTER TABLE table_name ADD INDEX index_name(col_name);
```
- 创建表的时候同时创建索引
```mysql
CREATE TABLE `news` (
`id` int(11) NOT NULL AUTO_INCREMENT ,
`title` varchar(255) NOT NULL ,
`content` varchar(255) NULL ,
`time` varchar(20) NULL DEFAULT NULL ,
PRIMARY KEY (`id`),
INDEX index_name (title(255))
)
```
- 删除索引
```mysql
DROP INDEX index_name ON table_name;
# 或
alter table `表名` drop index 索引名;
```
### 复合索引
**复合索引（组合索引）**：复合索引是在多个字段上创建的索引。复合索引遵守“**最左前缀**”原则**，
- 创建一个复合索引
```mysql
create index index_name on table_name(col_name1,col_name2,...);
```
- 修改表结构的方式添加索引
```mysql
alter table table_name add index index_name(col_name,col_name2,...);
```
### 唯一索引
**唯一索引**：唯一索引和普通索引类似，主要的区别在于，**唯一索引限制列的值必须唯一，但允许存在空值（只允许存在一条空值）**。如果在已经有数据的表上添加唯一性索引的话：
- 如果添加索引的列的值存在两个或者两个以上的空值，则不能创建唯一性索引会失败。（一般在创建表的时候，要对自动设置唯一性索引，需要在字段上加上 not null）
- 如果添加索引的列的值存在两个或者两个以上null值， ， ， ，
对于多个字段创建唯一索引规定列值的组合必须唯一。比如：
```mysql
“空值” 和”NULL”的概念：
1：
2: MySQL中的NULL其实是占用空间的.
长度验证：注意空值的之间是没有空格的。
> select length(''),length(null),length(' ');
+------------+--------------+-------------+
| length('') | length(null) | length(' ') |
+------------+--------------+-------------+
| 0 | NULL | 1 |
+------------+--------------+-------------+
```
- 创建唯一索引
```mysql
# 创建单个索引
CREATE UNIQUE INDEX index_name ON table_name(col_name);
# 创建多个索引
CREATE UNIQUE INDEX index_name on table_name(col_name,...);
```
- 修改表结构
```mysql
# 单个
ALTER TABLE table_name ADD UNIQUE index index_name(col_name);
# 多个
ALTER TABLE table_name ADD UNIQUE index index_name(col_name,...);
```
- 创建表的时候直接指定索引
```mysql
CREATE TABLE `news` (
`id` int(11) NOT NULL AUTO_INCREMENT ,
`title` varchar(255) NOT NULL ,
`content` varchar(255) NULL ,
`time` varchar(20) NULL DEFAULT NULL ,
PRIMARY KEY (`id`),
UNIQUE index_name_unique(title)
)
```
### 主键索引
主键索引是一种特殊的唯一索引，一个表只能有一个主键，不允许有空值。一般是在建表的时候同时创建主键索引：
- 主键索引(创建表时添加)
```mysql
CREATE TABLE `news` (
`id` int(11) NOT NULL AUTO_INCREMENT ,
`title` varchar(255) NOT NULL ,
`content` varchar(255) NULL ,
`time` varchar(20) NULL DEFAULT NULL ,
PRIMARY KEY (`id`)
)
```
- 主键索引(创建表后添加)
```mysql
alter table tbl_name add primary key(col_name);
```
```mysql
CREATE TABLE `order` (
`orderId` varchar(36) NOT NULL,
`productId` varchar(36) NOT NULL ,
`time` varchar(20) NULL DEFAULT NULL
)
alter table `order` add primary key(`orderId`);
```
### 全文索引
在一般情况下，模糊查询都是通过 like 的方式进行查询。但是，对于海量数据，这并不是一个好办法，在 like "value%" 可以使用索引，但是对于 like "%value%" 这样的方式，执行全表查询，这在数据量小的表，不存在性能问题，但是对于海量数据，全表扫描是非常可怕的事情，所以 like 进行模糊匹配性能很差。
这种情况下，需要考虑使用全文搜索的方式进行优化。全文搜索在 MySQL 中是一个 FULLTEXT 类型索引。**FULLTEXT 索引在 MySQL 5.6 版本之后支持 InnoDB，
全文索引主要用来查找文本中的关键字， ， ， ， ，
**小技巧**
在数据量较大时候， ， ，
- 创建表的适合添加全文索引
```mysql
CREATE TABLE `news` (
`id` int(11) NOT NULL AUTO_INCREMENT ,
`title` varchar(255) NOT NULL ,
`content` text NOT NULL ,
`time` varchar(20) NULL DEFAULT NULL ,
PRIMARY KEY (`id`),
FULLTEXT (content)
)
```
- 修改表结构添加全文索引
```mysql
ALTER TABLE table_name ADD FULLTEXT index_fulltext_content(col_name)
```
- 直接创建索引
```mysql
CREATE FULLTEXT INDEX index_fulltext_content ON table_name(col_name)
```
**注意**： ！
- 索引的查询和删除
```mysql
-- 查看:
show indexes from `表名` ;
-- 或
show keys from `表名` ;
-- 删除
alter table `表名` drop index 索引名;
```
**注意**： ，
## 索引优缺点
### 索引优点
- 提高数据检索的效率， ，
- 降低数据库的排序成本。因为索引就是对字段数据进行排序后存储的， ， ， ， ， ，
### 索引缺点
- 索引会增加 增、删、改操作所带来的IO量与调整索引的计算量
- 索引要占用空间，随着数据量的不断增大，索引还会带来存储空间的消耗
## 失效场景
**场景一： ，
使用or并不是一定会使索引失效，
```sql
-- 假设user表中的user_id列有索引，
-- 能命中索引
select * from user where user_id = 1 or user_id = 2;
-- 无法命中索引
select * from user where user_id = 1 or age = 20;
-- 假设age列也有索引的话，
select * from user where user_id = 1 or age = 20;
```
可以根据情况尽量使用union all或者in来代替，
**场景二： ，
负向查询包括： < >、!< 、!>、NOT IN、NOT LIKE等。其实负向查询并不绝对会索引失效， ，
**场景三： ， ，
其实单个索引字段， ，
**场景四：在索引列上使用内置函数，一定会导致索引失效**
比如下面语句中索引列login_time上使用了函数， ：
```sql
select * from user where DATE_ADD(login_time, INTERVAL 1 DAY) = 7;
```
**场景五：隐式类型转换导致的索引失效**
如下面语句中索引列user_id为varchar类型， ：
```mysql
select * from user where user_id = 12;
```
**场景六：对索引列进行运算，一定会导致索引失效**
运算如+， ， ，
```mysql
select * from user where age - 1 = 10;
```
优化的话，要把运算放在值上，或者在应用程序中直接算好，比如：
```sql
select * from user where age = 10 - 1;
```
**场景七：
like查询以%开头时，会导致索引失效。解决办法有两种：
- 将%移到后面，如：
```sql
select * from user where `name` like '李%';
```
- 利用覆盖索引来命中索引：
```sql
select name from user where `name` like '%李%';
```
**场景八： ， ，
当创建一个联合索引的时候，如(k1,k2,k3)，相当于创建了(k1)、(k1,k2)和(k1,k2,k3)三个索引，这就是最左匹配原则。比如下面的语句就不会命中索引：
```sql
select * from t where k2=2;
select * from t where k3=3;
select * from t where k2=2 and k3=3;
```
下面的语句只会命中索引(k1)：
```sql
select * from t where k1=1 and k3=3;
```
## 优化建议
- **禁止在更新十分频繁、区分度不高的属性上建立索引**
- 更新会变更B+树，更新频繁的字段建立索引会大大降低数据库性能。
- “性别”这种区分度不大的属性，建立索引是没有什么意义的，不能有效过滤数据，性能与全表扫描类似。
- **建立组合索引，必须把区分度高的字段放在前面**
# SQL优化
## SQL优化步骤
**第1步：
**第2步：
需要重点关注`type`、`rows`、`filtered`、`extra`。
- `type` ：由上至下，效率越来越高
- `ALL` ：全表扫描
- `index` ：索引全扫描
- `range` ：索引范围扫描，常用语`< `、`< =`、`>=`、`between`、`in`等操作
- `ref` ：使用非唯一索引扫描或唯一索引前缀扫描，返回单条记录，常出现在关联查询中
- `eq_ref` ： ， ，
- `const/system` ：单条记录，系统会把匹配行中的其他列作为常数处理，如主键或唯一索引查询
- `null` ： ，
虽然上至下， ， ， ， ， ， ， ； ， ， ，
- `Extra`
- `Using filesort` ： ， ，
- `Using temporary` ：使用了临时表保存中间结果，性能特别差，需要重点优化
- `Using index` ：表示相应的 select 操作中使用了覆盖索引（ ） ，
- `Using index condition` ： ， （ ） ， ， ，
**第3步：
了解SQL执行的线程的状态及消耗的时间。默认是关闭的，
```mysql
SHOW PROFILES ;
SHOW PROFILE FOR QUERY #{id};
```
**第4步：
trace分析优化器如何选择执行计划，
```mysql
set optimizer_trace="enabled=on";
set optimizer_trace_max_mem_size=1000000;
select * from information_schema.optimizer_trace;
```
**第5步：
- 优化索引
- 优化SQL语句：
- 改用其他实现方式：
- 数据碎片处理
## 特殊需求
### 批量去重插入
**问题： ， ？
**解决方案1：
当插入数据时， ， ， ， ， ：
```mysql
INSERT IGNORE INTO user (name) VALUES ('telami')
```
这种方法很简便，但是有一种可能，就是插入不是因为重复数据报错，而是因为其他原因报错的，也同样被忽略了～
**解决方案2：
当primary或者unique重复时， ， ， ， ， ， ：
```mysql
INSERT INTO user (name) VALUES ('telami') ON duplicate KEY UPDATE id = id
```
这种方法有个前提条件，就是，需要插入的约束，需要是主键或者唯一约束（在你的业务中那个要作为唯一的判断就将那个字段设置为唯一约束也就是`unique key`）。
**解决方案3：
根据select的条件判断是否插入，
```mysql
INSERT INTO user (name) SELECT 'telami' FROM dual WHERE NOT EXISTS (SELECT id FROM user WHERE id = 1)
```
这种方法其实就是使用了`MySQL`的一个临时表的方式，但是里面使用到了子查询，效率也会有一点点影响，如果能使用上面的就不使用这个。
**解决方案4：
如果存在`primary or unique`相同的记录，则先删除掉。再插入新记录。
```mysql
REPLACE INTO user SELECT 1, 'telami' FROM books
```
这种方法就是不管原来有没有相同的记录，都会先删除掉然后再插入。选择的是第二种方式
```xml
< insert id = "batchSaveUser" parameterType = "list" >
insert into user (id,username,mobile_number)
values
< foreach collection = "list" item = "item" index = "index" separator = "," >
(
#{item.id},
#{item.username},
#{item.mobileNumber}
)
< / foreach >
ON duplicate KEY UPDATE id = id
< / insert >
```
这里用的是Mybatis， ，
## 场景分析
### 案例1：
**索引**
```mysql
KEY `idx_shopid_orderno` (`shop_id`,`order_no`)
```
**SQL语句**
```mysql
select * from _t where orderno='xxx';
```
查询匹配从左往右匹配，要使用`order_no`走索引，必须查询条件携带`shop_id`或者索引(`shop_id`,`order_no`)调换前后顺序。
### 案例2：
**索引**
```mysql
KEY `idx_mobile` (`mobile`)
```
**SQL语句**
```mysql
select * from _user where mobile=12345678901;
```
隐式转换相当于在索引上做运算， ， ， ， ，
### 案例3：
**索引**
```mysql
KEY `idx_a_b_c` (`a`, `b` , `c` )
```
**SQL语句**
```mysql
select * from _t where a = 1 and b = 2 order by c desc limit 10000, 10;
```
对于大分页的场景，可以优先让产品优化需求，如果没有优化的，有如下两种优化方式：
- 把上一次的最后一条数据， ， < xxx ”处理，但是这种一般需要改接口协议，并不一定可行
- 采用延迟关联的方式进行处理， ， ，
```mysql
SELECT t1.* FROM _t t1, (SELECT id FROM _t WHERE a=1 AND b=2 ORDER BY c DESC LIMIT 10000,10) t2 WHERE t1.id=t2.id;
```
### 案例4：
**索引**
```mysql
KEY `idx_shopid_status_created` (`shop_id`, `order_status` , `created_at` )
```
**SQL语句**
```mysql
SELECT * FROM _order WHERE shop_id = 1 AND order_status IN ( 1, 2, 3 ) ORDER BY created_at DESC LIMIT 10
```
in查询在MySQL底层是通过`n*m`的方式去搜索， ， （ ） ， ， ， ， ，
因此会导致执行计划选择不准确。默认是200， ， ， ， `created_at` )互换前后顺序，
### 案例5：
范围查询阻断，后续字段不能走索引。
**索引**
```mysql
KEY `idx_shopid_created_status` (`shop_id`, `created_at` , `order_status` )
```
**SQL语句**
```mysql
SELECT * FROM _order WHERE shop_id=1 AND created_at > '2021-01-01 00:00:00' AND order_status=10;
```
范围查询还有“IN、between”。
### 案例6：
不等于、不包含不能用到索引的快速搜索。
```mysql
select * from _order where shop_id=1 and order_status not in (1,2);
select * from _order where shop_id=1 and order_status != 1;
```
在索引上，避免使用`NOT`、`!=`、`< >`、`!< `、`!>`、`NOT EXISTS`、`NOT IN`、`NOT LIKE`等。
### 案例7：
如果要求访问的数据量很小， ， （
```mysql
select * from _order where order_status = 1
```
查询出所有未支付的订单，一般这种订单是很少的，即使建了索引，也没法使用索引。
### 案例8：
```mysql
select sum(amt) from _t where a = 1 and b in (1, 2, 3) and c > '2020-01-01';
select * from _t where a = 1 and b in (1, 2, 3) and c > '2020-01-01' limit 10;
```
如果是统计某些数据， ； ， ， ，
### 案例9：
```mysql
select * from _t where a=1 order by b desc, c asc
```
desc 和asc混用时会导致索引失效
### 案例10：
对于推送业务的数据存储， ， ， ， ， ， ，
# 存储引擎
InnoDB 和 MyISAM 的比较
- 事务：
- 并发：
- 外键：
- 备份：
- 崩溃恢复：
- 其它特性：
## InnoDB引擎
InnoDB 是一个事务安全的存储引擎， ，
**特点**
- 支持事务， （ ）
- 行级锁定（更新时锁定当前行）
- 读写阻塞与事务隔离级别相关
- 既能缓存索引又能缓存数据
- 支持外键
- InnoDB更消耗资源，
- 在InnoDB中存在着缓冲管理， ， ， ；
- 对于InnoDB类型的表， ，
**业务场景**
- 需要支持事务的场景（银行转账之类）
- 适合高并发，行级锁定对高并发有很好的适应能力，但需要确保查询是通过索引完成的
- 数据修改较频繁的业务
**InnoDB引擎调优**
- 主键尽可能小，
- 避免全表扫描，这会造成锁表
- 尽可能缓存所有的索引和数据，
- 避免主键更新，这会造成大量的数据移动
## MyISAM引擎
MyISAM既不支持事务、也不支持外键、其优势是访问速度快， ，
**特点**
- 不支持事务
- 表级锁定（更新时锁定整个表）
- 读写互相阻塞（写入时阻塞读入、读时阻塞写入；但是读不会互相阻塞）
- 只会缓存索引（ ， ）
- 不支持外键
- 读取速度快
**业务场景**
- 不需要支持事务的场景（像银行转账之类的不可行）
- 一般读数据的较多的业务
- 数据修改相对较少的业务
- 数据一致性要求不是很高的业务
**MyISAM引擎调优**
- 设置合适索引
- 启用延迟写入，尽量一次大批量写入，而非频繁写入
- 尽量顺序insert数据， ，
- 降低并发数，高并发使用排队机制
- MyISAM的count只有全表扫描比较高效，
# MySQL原理
## 架构设计
从上面的示意图可以看出， ：
- **客户端**： ，
- **Server层**： ， ，
- **存储层**： ， ，
### 连接器
连接器是MySQL服务端对外的门户， ， ， ； ， ， ， ，
### 查询缓存
当连接建立完成后， ， ，
但是常我们不会使用MySQL自身的查询缓存，
### 分析器
如果在查询缓存中没有查到数据， ， ， ， ，
### 优化器
当分析器处理过之后， ， ，
### 执行器
执行阶段，首先会检查当前用户有没有权限操作该 SQL 语句。如果有，则继续执行后续的操作。
## 日志系统
**生产优化**
- 在生产上，建议 innodb_flush_log_at_trx_commit 设置成 1， ，
- 建议 sync_binlog 设置成 1， ，
**IO性能优化**
- `binlog_group_commit_sync_delay` ：表示延迟多少微秒后，再执行 `fsync`
- `binlog_group_commit_sync_no_delay_count` ：表示累计多少次后，在调用 `fsync`
当 `MySQL` 出现了 `IO` 的性能问题，可以考虑下面的优化策略：
- 设置 `binlog_group_commit_sync_delay` 和 `binlog_group_commit_sync_no_delay_count` 。可以使用故意等待来减少，`binlog` 的写盘次数，没有数据丢失的风险，但是会有客户端响应变慢的风险
- 设置 `sync_binlog` 设置为 `100~1000` 之间的某个值。这样做存在的风险是可能造成 `binlog` 丢失
- 设置 `innodb_flush_log_at_trx_commit = 2` ，可能会丢数据
### redo log(重做日志)
在MySQL里， ， ， （ ） ， ， ， ， ， ， ：
write pos 是当前要写入日志的位置， ， ， ， ，
**redo log写入流程**
前面介绍过了 redo log 的写入首先会写入 redo log cache， ：
redo log 对应上面的 3 种状态分别是：
- **在 MySQL 应用的 redo log buffer 中**
- **write 到文件系统的 page cache 中， （ ）
- **执行 fsync 之后，写盘结束**
InnoDB 有一个后台线程，每个 1 秒钟 就会将 redo log buffer 中的日志，调用 write 写入到 文件系统的 page cache 中，然后再调用 fsync 持久化到磁盘中。redo log buffer 是共享的，因此一些正在执行中的事务的 redo log 也有可能被持久化到磁盘中。
通常我们说的 MySQL 的 “双1” 操作，指的是 `sync_binlog = 1 AND innodb_flush_log_at_trx_commit = 1` 。`innodb_flush_log_at_trx_commit` 设置成 `1` 表示 redo log 在 prepare 阶段就需要持久化一次，那么 “双1” 配置 每个事务提交的时候都会刷盘 2 次，一次是 `binlog` ，一次是 `redo log` 。
为了控制 redo log 的写入策略，
- **0：
- **1：
- **2：
redo log 实际的触发 fsync 操作写盘包含以下几个场景：
- **后台每隔 1 秒钟的线程轮询**
- **innodb_flush_log_at_trx_commit 设置成 1 时，事务提交时触发**
- **innodb_log_buffer_size 是设置 redo log 大小的参数**。当 redo log buffer 达到 innodb_log_buffer_size / 2 时，也会触发一次 fsync
### binlog(归档日志)
通过MySQL的架构可以看出， ： ， ， ， ， ， ：
结合到update 语句中， ：
从上面的执行流程可以看出，
**binlog写入流程**
事务执行过程中， ； ，
系统为每个客户端线程分配一个 binlog cache，
从上面可以看出，每个客户端线程都有自己独立的 binlog cache， ， ， ，
- sync_binlog=0： ，
- sync_binlog=1：
- sync_binlog=N（ ） ： ，
在出现 IO 瓶颈的情况下，可以考虑将 sync_binlog 设置成一个大的值。比较常见的是将 N设置为 100~1000。但是存在的风险是，
## 查询过程
## 全局锁表锁&行锁
### 全局锁
**FTWRL**
全局锁就是对整个数据库实例加锁，
**mysqldump**
mysqldump 是官方提供的备份工具，可以通过 --single-transaction 参数来启用可重复读隔离级别，从而可以拿到一个一致性视图。
**set global readonly = true**
通过上述命令可以让全库进入只读状态，但是在开发当中，事务框架往往会利用这个参数来处理读写分离。所以通常情况下，还是不建议使用这种方式。
### 表级锁
MySQL 的表级锁有 2 种：表锁和元数据锁。
**表锁**
表锁可以使用 lock tables T read/write , 可以使用 unlock tables 主动释放锁，也可以在客户端断开的时候自动释放锁。
**MDL (metadata lock)**
MDL 没有显示的命令， ，
- MDL 读锁之间不互斥，因此可以有多个线程同时对一张表 增删改查
- MDL 读-写、写-写之间是互斥的，因此如果同时有 2 个线程给表加字段，则需要顺序执行
### 行锁
**两阶段锁**
当使用update 更新数据时，会对 where 条件扫描到的行加行锁。在 InnoDB 事务中，行锁是在需要的时候才加上的，并且在事务提交后释放的，这就是两阶段锁协议。所以我们在更新数据时，应尽量把容易产生并发更新的行放在事务末端执行。
**死锁**
在事务对不同行加锁的时候，就很有可能出现死锁的情况。
MySQL 有 2 中策略去解决死锁：
- **超时等待**：可以通过 innodb_lock_wait_timeout 来设置，默认 50S。（ ，
- **死锁检测**：发现死锁后，主动回滚其中一个事务。可以通过 innodb_deadlock_detect 设置为 on
上面 2 种死锁的解决方法，
- **按规则加锁**：如 A 转账给 B， ，
- **控制并发度**：如支付系统中的账户系统，可以将总账户拆分成子账户，然后每个子账户是一个独立的锁实体
## mysql复制原理
### 基于语句的复制
基于语句的复制模式下， ， ，
- **优点**
最明显的好处是实现相当简单。理论上讲， ， ， ，
- **缺点**
有些数据更新语句， ， ， ， ， ， ， ， ，
### 基于行的复制
MySQL5.1开始支持基于行的复制，这种方式会将实际数据记录在二进制日志中，跟其他数据库的实现比较相像。
- **优点**
最大的好处是可以正确的复制每一行，一些语句可以呗更加有效地复制。由于无需重放更新主库数据的查询，使用基于行的复制模式能够更高效地复制数据。重放一些查询的代价会很高
- **缺点**
全表更行，使用基于行复制开销会大很多，因为每一行数据都会呗记录到二进制日志中，这使得二进制日志时间非常庞大
# InnoDB原理
## Buffer Pool
`InnoDB` 为了解决磁盘`IO`问题，`MySQL`需要申请一块内存空间，这块内存空间称为`Buffer Pool`。
### 缓存页
`Buffer Pool` 申请下来后，`Buffer Pool`里面放什么，要怎么规划？
`MySQL` 数据是以页为单位，每页默认`16KB`，称为数据页，在`Buffer Pool`里面会划分出若干**个缓存页**与数据页对应。
### 描述数据
# 高可用方案
我们在考虑MySQL数据库的高可用架构时， ：
- 如果数据库发生了宕机或者意外中断等故障，能尽快恢复数据库的可用性，尽可能的减少停机时间，保证业务不会因为数据库的故障而中断
- 用作备份、只读副本等功能的非主节点的数据应该和主节点的数据实时或者最终保持一致
- 当业务发生数据库切换时，切换前后的数据库内容应当一致，不会因为数据缺失或者数据不一致而影响业务
关于对高可用的分级我们暂不做详细的讨论，这里只讨论常用高可用方案的优缺点以及选型。
随着人们对数据一致性要求不断的提高， ，
而使用分布式算法用来解决MySQL数据库数据一致性问题的方法， ，
随着官方MySQL Group Replication的GA， ，
## 主从或主主半同步复制
使用双节点数据库， ， ， ：
通常会和Proxy、Keepalived等第三方软件同时使用， ， ，
**优点**
- 架构比较简单，使用原生半同步复制作为数据同步的依据
- 双节点，没有主机宕机后的选主问题，直接切换即可
- 双节点，需求资源少，部署简单
**缺点**
- 完全依赖于半同步复制，如果半同步复制退化为异步复制，数据一致性无法得到保证
- 需要额外考虑HAProxy、Keepalived的高可用机制
## 半同步复制优化
半同步复制机制是可靠的。如果半同步复制一直是生效的，那么可以认为数据是一致的。但是由于网络波动等一些客观原因，导致半同步复制发生超时而切换为异步复制，这时便不能保证数据的一致性。所以尽可能的保证半同步复制，就可以提高数据的一致性。
该方案同样使用双节点架构，但是在原有半同复制的基础上做了功能上的优化，使半同步复制的机制变得更加可靠。可参考的优化方案如下：
### 双通道复制
半同步复制由于发生超时后，复制断开，当再次建立起复制时，同时建立两条通道，其中一条半同步复制通道从当前位置开始复制，保证从机知道当前主机执行的进度。另外一条异步复制通道开始追补从机落后的数据。当异步复制通道追赶到半同步复制的起始位置时，恢复半同步复制。
### binlog文件服务器
搭建两条半同步复制通道，其中连接文件服务器的半同步通道正常情况下不启用，当主从的半同步复制发生网络问题退化后，启动与文件服务器的半同步复制通道。当主从半同步复制恢复后，关闭与文件服务器的半同步复制通道。
**优点**
- 双节点，需求资源少，部署简单
- 架构简单，没有选主的问题，直接切换即可
- 相比于原生复制，优化后的半同步复制更能保证数据的一致性
**缺点**
- 需要修改内核源码或者使用MySQL通信协议。需要对源码有一定的了解，
- 依旧依赖于半同步复制，没有从根本上解决数据一致性问题
## 高可用架构优化
将双节点数据库扩展到多节点数据库，或者多节点数据库集群。可以根据自己的需要选择一主两从、一主多从或者多主多从的集群。由于半同步复制，存在接收到一个从机的成功应答即认为半同步复制成功的特性，所以多从半同步复制的可靠性要优于单从半同步复制的可靠性。并且多节点同时宕机的几率也要小于单节点宕机的几率，所以多节点架构在一定程度上可以认为高可用性是好于双节点架构。
但由于数据库数量较多， ：
### MHA+多节点集群
MHA Manager会定时探测集群中的master节点， ， ， ， ， ， ：
**优点**
- 可以进行故障的自动检测和转移
- 可扩展性较好，
- 相比于双节点的MySQL复制，
**缺点**
- 至少需要三节点，相对于双节点需要更多的资源
- 逻辑较为复杂，发生故障后排查问题，定位问题更加困难
- 数据一致性仍然靠原生半同步复制保证，仍然存在数据不一致的风险
- 可能因为网络分区发生脑裂现象。
- 在此我向大家推荐一个架构学习交流群。交流学习群号： ： ， ， ， ， ，
### ZooKeeper+Proxy
ZooKeeper使用分布式算法保证集群数据的一致性， ，
**优点**
- 较好的保证了整个系统的高可用性，
- 扩展性较好，可以扩展为大规模集群
**缺点**
- 数据一致性仍然依赖于原生的mysql半同步复制
- 引入ZK，
## 共享存储
共享存储实现了数据库服务器和存储设备的解耦， ， ，
### SAN共享储存
SAN的概念是允许存储设备和处理器（ ） （ ） ， ：
使用共享存储时， ， ， ，
**优点**
- 两节点即可，部署简单，切换逻辑简单
- 很好的保证数据的强一致性
- 不会因为MySQL的逻辑错误发生数据不一致的情况
**缺点**
- 需要考虑共享存储的高可用
- 价格昂贵
### DRBD磁盘复制
DRBD是一种基于软件、基于网络的块复制存储解决方案， ， ， ，
当本地主机出现问题， ， ， ，
**优点**
- 两节点即可，部署简单，切换逻辑简单
- 相比于SAN储存网络，
- 保证数据的强一致性
**缺点**
- 对IO性能影响较大
- 从库不提供读操作
## 分布式协议
分布式协议可以很好地解决数据一致性问题。比较常见的方案如下：
### MySQL Cluster
MySQL Cluster是官方集群的部署方案， ，
**优点**
- 全部使用官方组件，不依赖于第三方软件
- 可以实现数据的强一致性
**缺点**
- 国内使用的较少
- 配置较复杂， ，
- 至少三节点
### Galera
基于Galera的MySQL高可用集群， ， ， ， ：
**优点**
- 多主写入，无延迟复制，能保证数据强一致性
- 有成熟的社区，有互联网公司在大规模的使用
- 自动故障转移，自动添加、剔除节点
**缺点**
- 需要为原生MySQL节点打wsrep补丁
- 只支持innodb储存引擎
- 至少三节点
### Paxos
Paxos算法解决的问题是一个分布式系统如何就某个值（ ） ：
**优点**
- 多主写入，无延迟复制，能保证数据强一致性
- 有成熟理论基础
- 自动故障转移，自动添加、剔除节点
**缺点**
- 只支持InnoDB储存引擎
- 至少三节点
- 在此我向大家推荐一个架构学习交流群。交流学习群号： ： ， ， ， ， ，
## 主从延迟
在实际的生产环境中， ， ， ， （ ） ， （ ） ：
- 提高数据库负载能力，主库执行读写任务（增删改），备库仅做查询
- 提高系统读写性能、可扩展性和高可用性
- 数据备份与容灾，备库在异地，主库不存在了，备库可以立即接管，无须恢复时间
### biglog
**binlog是什么？ ？
用于记录数据库执行的写入性操作(不包括查询)信息， `Server` 层进行记录，使用任何存储引擎的 mysql 数据库都会记录 binlog 日志。在实际应用中， binlog 的主要使用场景有两个：
- 用于主从复制， ， ，
- 用于数据备份， ， ，
**日志格式**
binlog日志有三种格式， ， `binlog-format` 指定。
- **STATMENT** ：基于 SQL 语句的复制，
- **ROW** ：基于行的复制
- **MIXED** ：基于 STATMENT 和 ROW 两种模式的混合复制，比如一般的数据操作使用 row 格式保存，有些表结构的变更语句，使用 statement 来记录
我们还可以通过mysql提供的查看工具mysqlbinlog查看文件中的内容， ：
```mysql
mysqlbinlog mysql-bin.00001 | more
```
binlog文件大小和个数会不断的增加， ，
### 主从复制原理
可以看到mysql主从复制需要三个线程： （ ） （ ）
- **binlog dump线程： ， ， ， ，
- **I/O线程： ， ，
- **SQL线程： ， ， ，
**基本过程总结**
- 主库写入数据并且生成binlog文件。该过程中MySQL将事务串行的写入二进制日志，
- 在事件写入二进制日志完成后，
- 从库服务器上的IO线程连接Master服务器，
- 主库接收到从库IO线程请求后，
- Slave服务器的IO线程获取到Master服务器上IO线程发送的日志内容、日志文件及位置点后， （ ） ， ，
- 从库服务器的SQL线程会实时监测到本地Relay Log中新增了日志内容，
- 从库在`relay-log.info`中记录当前应用中继日志的文件名和位置点以便下一次数据复制
**并行复制**
在MySQL 5.6版本之前， ， ， ， ：
**上图的红色框框部分就是实现并行复制的关键所在**。这意味着coordinator线程并不是仅将日志发送给worker线程， ，
不过到MySQL 5.7才可称为真正的并行复制， ， ，
- **DATABASE**：默认值，基于库的并行复制方式
- **LOGICAL_CLOCK**：基于组提交的并行复制方式
**按库并行**
每个 worker 线程对应一个 hash 表， ， ， ， ， ， ， ， ， ：
**组提交优化**
该特性如下：
- 能够同一组里提交的事务，定不会修改同一行
- 主库上可以并行执行的事务，从库上也一定可以并行执行
具体是如何实现的：
- 在同一组里面一起提交的事务，会有一个相同的`commit_id`，下一组为`commit_id+1`，该`commit_id`会直接写到binlog中
- 在从库使用时，相同`commit_id`的事务会被分发到多个worker并行执行， ，
### 主从延迟
根据主从复制的原理可以看出，两者之间是存在一定时间的数据不一致，也就是所谓的主从延迟。导致主从延迟的时间点：
- 主库 A 执行完成一个事务，写入 binlog，
- 传给从库B，
- 从库B执行完这个事务，
那么所谓主从延迟， ， ，
**seconds_behind_master如何计算的？
- 每一个事务的binlog都有一个时间字段，
- 从库取出当前正在执行的事务的时间字段，跟当前系统的时间进行相减，得到的就是`seconds_behind_master`，
**为什么会主从延迟？**
正常情况下， ， ， （ ） ， ：
- **从库的机器性能比主库要差**
比如将20台主库放在4台机器， ， ， ， ，
- **从库的压力大**
按照正常的策略， ， ， ， ， ， ， ， ； ， ，
- **大事务的执行**
一旦执行大事务， ， ， ， ， ， ，
- **主库的DDL(alter、drop、create)**
- 只读节点与主库的DDL同步是串行进行， ， ， ，
- 从节点上有一个执行时间非常长的的查询正在执行， ， ， ，
- **锁冲突**
锁冲突问题也可能导致从节点的SQL线程执行慢， ，
- **从库的复制能力**
一般场景中，因偶然情况导致从库延迟了几分钟，都会在从库恢复之后追上主库。但若是从库执行速度低于主库，且主库持续具有压力，就会导致长时间主从延迟，很有可能就是从库复制能力的问题。
从库上的执行，即`sql_thread`更新逻辑， ， ， ， ， `slave_parallel_workers` 为一个大于0的数，
```mysql
mysql> show variables like 'slave_parallel%';
+------------------------+----------+
| Variable_name | Value |
+------------------------+----------+
| slave_parallel_type | DATABASE |
| slave_parallel_workers | 0 |
+------------------------+----------+
```
**怎么减少主从延迟？**
主从同步问题永远都是一致性和性能的权衡，得看实际的应用场景，若想要减少主从延迟的时间，可以采取下面的办法：
- 降低多线程大事务并发的概率，优化业务逻辑
- 优化SQL， ， ，
- 提高从库机器的配置，
- 尽量采用短的链路， ， ，
- 实时性要求的业务读强制走主库，从库只做灾备，备份
# 常见问题
## MySQL事务
**问题一： ？ ？ ？
在Mysql中事务的四大特性（
- **原子性（ ） ，
- **一致性**：是指**执行事务前后的状态要一致**，可以理解为数据一致性
- **隔离性**：侧重指**事务之间相互隔离，不受影响**，这个与事务设置的隔离级别有密切的关系
- **持久性**：则是指在**一个事务提交后，这个事务的状态会被持久化到数据库中，也就是事务提交，对数据的新增、更新将会持久化到数据库中**
在我的理解中：**原子性、隔离性、持久性都是为了保障一致性而存在的，一致性也是最终的目的**。
Mysql中事务的隔离级别分为四大等级：
- **读未提交（ ）
- **读提交 （ ）
- **可重复读 （ ）
- **串行化 （ ）
没有哪种隔离级别是完美的， ， ：
- **读未提交：读取到别的事务还没有提交的数据，从而产生了脏读**
- **读提交：读取别的事务已经提交的数据，从而产生不可重复读**
- **可重复读： ， ，
- **串行化：对于同一行记录，若是读写锁发生冲突，后面访问的事务只能等前面的事务执行完才能继续访问**
## MySQL存储引擎
**问题二： ？
- InnoDB和MyISAM都是Mysql的存储引擎， ， ， ， ，
- 数据的存储上：
- 数据文件构成： ： ，
- 查询区别： ， ，
- coun(\*)区别： ， ， ， ，
- 其它的区别： ， ， ， ，
## SQL查询流程
**问题三： ？
当执行一条查询的SQl的时候大概发生了以下的步骤：
- 客户端发送查询语句给服务器
- 服务器首先进行用户名和密码的验证以及权限的校验
- 然后会检查缓存中是否存在该查询，若存在，返回缓存中存在的结果。若是不存在就进行下一步
- 接着进行语法和词法的分析， ，
- Mysql的执行器根据优化器生成的执行计划执行，
- 服务器将查询的结果返回客户端。
SQL查询流程图如下：
****
## MySQL Log
**问题四： ？
- redo log
- `redo log` 日志也叫做`WAL`技术（`Write- Ahead Logging`），他是一种**先写日志，并更新内存，最后再更新磁盘的技术**， ， ，
- `redo log` 是固定大小， ， ，
- `redo log` 日志实现了即使在数据库出现异常宕机的时候，重启后之前的记录也不会丢失，这就是`crash-safe`能力
- binlog
- `binlog` 称为**归档日志**， ， ， ， ： ，
redo log和binlog记录的形式、内容不同， ， ， ， ，
## MySQL索引种类
**问题五：你知道有哪些种类的索引？**
索引从**数据结构**进行划分的分为：**B+树索引、hash索引、R-Tree索引、FULLTEXT索引**。
索引从**物理存储**的角度划分为：**聚族索引**和**非聚族索引**。
从**逻辑的角度**分为：**主键索引**、**普通索引、唯一索引、联合索引**以及**空间索引**。
## MySQL索引
**问题六：怎么查看索引是否生效？什么情况下索引会失效呢？**
查看索引是否起作用可以使用explain关键字， ， ，
- `id` ：查询的序列号
- `select_type` ：查询类型
- `table` ：查询表名
- `type` ： ，
- `possible_keys` ：可是使用到的索引
- `key` ：实际使用到的索引
- `rows` ：
- `Extra` ： ，
- **where条件查询中使用了or关键字**， ， ， ，
- **条件查询中使用like关键字，
- **条件查询的字段是字符串，
- 对于**联合索引查询不符合最左前缀原则**，也会导致索引失效，如下所示：
```sql
alter table user add index union_index(name, age) // name左边的列，
select * from user where name = 'lidu' // 会用到索引
select * from user where age = 18 // 不会使用索引
```
- 在**where条件查询的后面对字段进行null值判断**， ， ：
```sql
SELECT id FROM table WHERE num is null
```
- 在**where子句中使用!= ,< >这样的符号**，也会导致索引失效。
```sql
SELECT id FROM table WHERE num != 0
```
- **where条件子句中=的左边使用表达式操作或者函数操作**，也会导致索引失效。
```sql
SELECT id FROM user WHERE age / 2 = 1
SELECT id FROM user WHERE SUBSTRING(name,1,2) = 'lidu'
```
