@ -346,9 +346,9 @@ ON A.PK = B.PK;
## 全连接（ OUTER JOIN）
## 全连接（ ）
FULL OUTER JOIN 一般被译作外连接、全连接，实际查询语句中可以写作 FULL OUTER JOIN 或 FULL JOIN。外连接查询能返回左右表里的所有记录， （ ）
FULL JOIN 一般被译作外连接、全连接，实际查询语句中可以写作 FULL OUTER JOIN 或 FULL JOIN。外连接查询能返回左右表里的所有记录， （ ）
**文氏图**
@ -461,7 +461,7 @@ WHERE A.PK IS NULL;
## FULL OUTER JOIN EXCLUDING INNER JOIN
## FULL JOIN EXCLUDING INNER JOIN
返回左表和右表里没有相互关联的记录集。
@ -610,167 +610,204 @@ WHERE A.EMP_SUPV_ID = B.EMP_ID;
**原子性（ ）
事务包含的操作要么全部成功，要么全部失败回滚 。
事务是数据库的逻辑工作单位，事务中包含的各操作要么都做，要么都不做 。
**一致性（ ）
事 务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统 运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是 不一致的状态。
一个事务执行前后， ， ， ，
**隔离性（ ）
多个用户并发访问数据库时，比如操作同一张表，数据库为每一个用户开启的事务，不能被其他事务的操作干扰。多个并发事务间需要隔离 。
一个事务的执行不能受到其它事务干扰。即一个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能互相干扰 。
**持久性（ ）
一旦一个事务被提交，对数据库中的数据改变是永久的，即使数据库系统故障，也不会丢失提交事务操作 。
指一个事务一旦提交，它对数据库中数据的改变就是永久性的。接下来的其它操作或故障不应该对其执行结果有任何影响 。
## 隔离级别
Oracle数据库中， （ ） （ ） ， 。不做隔离操作则会出现：
数据库事务隔离级别有4种， ： ** 脏读、不可重复读、幻读** 问题 。不做隔离操作则会出现：
- ** 脏读**：读到未提交更新的数据
- ** 脏读**：
- ** 不可重复读**：读到其它事务已经提交后的**更新**数据，即一个事务范围内两个相同的查询却返回了不同数据
- ** 幻读**： ， ，
- ** 第一类丢失更新**： ，
- ** 第二类丢失更新**： ，
- ** 不可重复读**：读到已经提交**更新**的数据，但一个事务范围内两个相同的查询却返回了不同数据
- ** 幻读**： ， ，
**默认隔离级别**
- Oracle仅有Serializable(串行化)和Read Committed(读已提交)两种隔离方式，默认选择**读已提交**的方式
- MySQL默认为**Repeatable Read（ ）
**InnoDB存储引擎下**的四种隔离级别发生问题的可能性如下：
| 隔离级别 | 第一类丢失更新 | 第二类丢失更新 | 脏读 | 不可重复读 | 幻读 |
| ---------------------------- | -------------- | -------------- | ---- | ---------- | ---- |
| SERIALIZABLE （串行化） | × × × × × |
| REPEATABLE READ（ ） × × × × |
| READ COMMITTED （读已提交） | × × |
| READ UNCOMMITTED（ ） × |
| 隔离级别 | 第一类丢失更新 | 第二类丢失更新 | 脏读 | 不可重复读 | 幻读 |
| -------------------------- | -------------- | -------------- | -------- | ---------- | ---- ---- |
| Read Uncommitted(读未提交) | 不可能 | ** 可能** | ** 可能** | ** 可能** | ** 可能** |
| Read Committed(读已提交) | 不可能 | ** 可能** | 不可能 | ** 可能** | ** 可能** |
| Repeatable Read(可重复读) | 不可能 | 不可能 | 不可能 | 不可能 | ** 可能** |
| Serializable(串行化) | 不可能 | 不可能 | 不可能 | 不可能 | 不可能 |
### Read Uncommitted(读未提交)
**即读取到了其它事务未提交的内容**。在该隔离级别，**所有事务都可以看到其他未提交事务的执行结果**。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为**脏读（ ）
### Serializable（ ）
**特点**：最低级别，任何情况都无法保证
指一个事务在执行过程中完全看不到其他事务对数据库所做的更新。当两个事务同时操作数据库中相同数据时，如果第一个事务已经在访问该数据，第二个事务只能停下来等待，必须等到第一个事务结束后才能恢复运行。因此这两个事务实际上是串行化方式运行。
**读未提交的数据库锁情况**
- 事务中读取数据：**未加锁**
- 事务中更新数据：**只对数据增加行级共享锁**
**特点**：避免脏读、不可重复读、幻读
**可序列化的数据库锁情况**
### Read Committed(读已提交)
- 事务在读取数据时，必须先对其加表级共享锁 ，直到事务结束才释放
- 事务在更新数据时，必须先对其加表级排他锁 ，直到事务结束才释放
**即读取到了其它事务已提交的内容**。一个事务只能看见已经提交事务所做的改变。这种隔离级别也支持所谓的**不可重复读（ ） ， ，
**特点**：避免脏读
**读已提交的数据库锁情况**
### Repeatable Read（ ）
- 事务中读取数据：**加行级共享锁（读到时才加锁），读完后立即释放**
- 事务中更新数据：**在更新时的瞬间对其加行级排它锁，直到事务结束才释放**
由于提交读隔离级别会产生不可重复读的读现象， ， （ ）
**Read Committed隔离级别下的加锁分析**
**特点**：
隔离级别的实现与锁机制密不可分， ， ：
**可重复读的数据库锁情况**
- ** 共享锁(S Lock)**： ， ， ， ， ， ，
- ** 排他锁(X Lock)**: 又称为写锁， ， ， ，
- 事务在读取某数据的瞬间（就是开始读取的瞬间），必须先对其加行级共享锁，直到事务结束才释放
- 事务在更新某数据的瞬间（就是发生更新的瞬间），必须先对其加行级排他锁，直到事务结束才释放
**注意**：
### Read Committed（ ）
### Repeatable Read(可重复读)
提交读（ ） ， ， ， ， 。
**它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行**。但会导致**幻读 （ ） 。
**幻读** 是户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当该用户再读取该范围的数据行时，会发现有新的“幻影” 行。
**特点**：
**特点**：避免脏读
**可重复读的数据库锁情况**
**提交读的数据库锁情况**
- 事务中读取数据：**开始读取的瞬间对其增加行级共享锁，直到事务结束才释放**
- 事务中更新数据：**开始更新的瞬间对其增加行级排他锁，直到事务结束才释放**
- 事务对当前被读取的数据加行级共享锁（当读到时才加锁），一旦读完该行，立即释放该行级共享锁
- 事务在更新某数据的瞬间（就是发生更新的瞬间），必须先对其加行级排他锁，直到事务结束才释放
### Serializable(可串行化)
**Read Committed隔离级别下的加锁分析**
**指一个事务在执行过程中完全看不到其他事务对数据库所做的更新**。当两个事务同时操作数据库中相同数据时，如果第一个事务已经在访问该数据，第二个事务只能停下来等待，必须等到第一个事务结束后才能恢复运行。因此这两个事务实际上是串行化方式运行。
隔离级别的实现与锁机制密不可分， ， ：
**特点**：避免脏读、不可重复读、幻读
- ** 共享锁(S Lock)**： ， ， ， ， ， ，
- ** 排他锁(X Lock)**: 又称为写锁， ， ， ，
**可序列化的数据库锁情况**
**注意**：
- 事务中读取数据：**先对其加表级共享锁 ，直到事务结束才释放**
- 事务中更新数据：**先对其加表级排他锁 ，直到事务结束才释放**
### Read uncommitted（ ）
## SpringBoot Transaction
未提交读（ ） ， ， 。
查看 `mysql` 事务隔离级别：`show variables like 'tx_iso%';` 。
### 实现方式
在Spring中事务有两种实现方式：
**特点**：最低级别，任何情况都无法保证
- ** 编程式事务管理**：
- ** 声明式事务管理**：
**未提交读的数据库锁情况**
- 事务在读数据的时候并未对数据加锁
- 事务在修改数据的时候只对数据增加行级共享锁
### 提交方式
**默认情况下，数据库处于自动提交模式**。每一条语句处于一个单独的事务中，在这条语句执行完毕时，如果执行成功则隐式的提交事务，如果执行失败则隐式的回滚事务。
对于正常的事务管理， ， ， ， ， ， `connection.setAutoCommit(false);` ，在执行完之后在进行提交，`connection.commit();` 。
## SpringBoot Transaction
查看 `mysql` 事务隔离级别：`show variables like 'tx_iso%';`。
### 事务隔离级别
隔离级别是指若干个并发的事务之间的隔离程度。
### 事务管理方式
```java
@Transactional (isolation = Isolation.READ_UNCOMMITTED)
public void addGoods(){
......
}
```
在Spring中， ，
枚举类Isolation中定义了五种隔离级别：
- ** 编程式事务管理**： ，
- ** 声明式事务管理**： ， ， ， ， ，
- `DEFAULT` ：默认值。表示使用底层数据库的默认隔离级别。对大部分数据库而言，通常这值就是**READ_COMMITTED**
- `READ_UNCOMMITTED` ：该隔离级别表示一个事务可以读取另一个事务修改但还没有提交的数据。该级别不能防止脏读，不可重复读和幻读，因此很少使用该隔离级别
- `READ_COMMITTED` ：该隔离级别表示一个事务只能读取另一个事务已经提交的数据。该级别可以防止脏读，这也是大多数情况下的推荐值
- `REPEATABLE_READ` ：该隔离级别表示一个事务在整个过程中可以多次重复执行某个查询，并且每次返回的记录都相同。该级别可以防止脏读和不可重复读
- `SERIALIZABLE` ：所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别
### 事务提交方式
### 事务传播行为
默认情况下，数据库处于自动提交模式。每一条语句处于一个单独的事务中，在这条语句执行完毕时，如果执行成功则隐式的提交事务，如果执行失败则隐式的回滚事务。
对于正常的事务管理， ， ， ， ， ， `connection.setAutoCommit(false);` ，在执行完之后在进行提交，`connection.commit();` 。
事务的传播性一般用在事务嵌套的场景，如一个事务方法里面调用了另外一个事务方法，那两个方法是各自作为独立的方法提交还是内层事务合并到外层事务一起提交，这就需要事务传播机制配置来确定怎么样执行。
```java
@Transactional (propagation=Propagation.REQUIRED)
public void addGoods(){
......
}
```
枚举类Propagation中定义了七种事务传播机制如下：
### 事务隔离级别
- `REQUIRED` （ ）
隔离级别是指若干个并发的事务之间的隔离程度。TransactionDefinition 接口中定义了五个表示隔离级别的常量：
Spring默认的传播机制， ， ， ， ， ，
- **TransactionDefinition.ISOLATION_DEFAULT** ： ， ，
- **TransactionDefinition.ISOLATION_READ_UNCOMMITTED** ： ， ，
- **TransactionDefinition.ISOLATION_READ_COMMITTED** ：该隔离级别表示一个事务只能读取另一个事务已经提交的数据。该级别可以防止脏读，这也是大多数情况下的推荐值
- **TransactionDefinition.ISOLATION_REPEATABLE_READ** ：该隔离级别表示一个事务在整个过程中可以多次重复执行某个查询，并且每次返回的记录都相同。该级别可以防止脏读和不可重复读
- **TransactionDefinition.ISOLATION_SERIALIZABLE** ：所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别
- `REQUIRES_NEW` （ ， ）
该事务传播机制是每次都会新开启一个事务，同时把外层事务挂起，当当前事务执行完毕，恢复上层事务的执行。如果外层没有事务，执行当前新开启的事务即可
- `SUPPORTS` （ ）
### 事务传播行为
如果外层有事务，则加入外层事务，如果外层没有事务，则直接使用非事务方式执行。完全依赖外层的事务
- `NOT_SUPPORTED` （ ， ）
该传播机制不支持事务，如果外层存在事务则挂起，执行完当前代码，则恢复外层事务，无论是否异常都不会回滚当前的代码
- `NEVER` （ ）
该传播机制不支持外层事务，即如果外层有事务就抛出异常
所谓事务的传播行为是指， ， ， ：
- `MANDATORY` （ ）
- **TransactionDefinition.PROPAGATION_REQUIRED** ：如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。这是默认值
- **TransactionDefinition.PROPAGATION_REQUIRES_NEW** ：创建一个新的事务，如果当前存在事务，则把当前事务挂起
- **TransactionDefinition.PROPAGATION_SUPPORTS** ：如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行
- **TransactionDefinition.PROPAGATION_NOT_SUPPORTED** ：以非事务方式运行，如果当前存在事务，则把当前事务挂起
- **TransactionDefinition.PROPAGATION_NEVER** ：以非事务方式运行，如果当前存在事务，则抛出异常。
- **TransactionDefinition.PROPAGATION_MANDATORY** ：如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常
- **TransactionDefinition.PROPAGATION_NESTED** ： ， ； ，
与NEVER相反， ，
- `NESTED` （ ， ）
该传播机制的特点是可以保存状态保存点，当前事务回滚到某一个点，从而避免所有的嵌套事务都回滚，即各自回滚各自的，如果子事务没有把异常吃掉，基本还是会引起全部回滚的。
@ -784,14 +821,37 @@ Oracle数据库中， （ ） （
### 事务常用配置
- **readOnly** ： ， ， ， ：
- **rollbackFor** ：
- **rollbackForClassName** ：
- **noRollbackFor** ：该属性用于设置不需要进行回滚的异常类数组，当方法中抛出指定异常数组中的异常时，不进行事务回滚。例如：指定单一异常类：@Transactional(noRollbackFor=RuntimeException.class)指定多个异常类：@Transactional(noRollbackFor={RuntimeException.class, Exception.class})
- **noRollbackForClassName** ：该属性用于设置不需要进行回滚的异常类名称数组，当方法中抛出指定异常名称数组中的异常时，不进行事务回滚。例如：指定单一异常类名称：@Transactional(noRollbackForClassName=”RuntimeException”)指定多个异常类名称：@Transactional(noRollbackForClassName={“RuntimeException”,”Exception”})
- **propagation** ：
- **isolation** ：该属性用于设置底层数据库的事务隔离级别，事务隔离级别用于处理多事务并发的情况，通常使用数据库的默认隔离级别即可，基本不需要进行设置
- **timeout** ：该属性用于设置事务的超时秒数，默认值为-1表示永不超时
- **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表示永不超时
@ -1288,62 +1348,132 @@ alter table `表名` drop index 索引名;
## 索引规范
## 索引优缺点
### 索引优点
- 提高数据检索的效率， ，
- 降低数据库的排序成本。因为索引就是对字段数据进行排序后存储的， ， ， ， ， ，
- ** 【强制】业务上具有唯一特性的字段，即使是多个字段的组合，也必须建成唯一索引。**
说明：不要以为唯一索引影响了 insert 速度，这个速度损耗可以忽略，但提高查找速度是明 显的；另外，即使在应用层做了非常完善的校验控制，只要没有唯一索引，根据墨菲定律，必 然有脏数据产生。
### 索引缺点
- ** 【强制】超过三个表禁止join。join字段数据类型必须绝对一致； ，
- 索引会增加 增、删、改操作所带来的IO量与调整索引的计算量
- 索引要占用空间，随着数据量的不断增大，索引还会带来存储空间的消耗
说明：即使双表 join 也要注意表索引、SQL 性能。
- 【**强制】在 varchar 字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据 实际文本区分度决定索引长度即可。**
说明：索引的长度与区分度是一对矛盾体，一般对字符串类型数据，长度为 20 的索引，区分 度会高达 90%以上，可以使用 count(distinct left(列名, 索引长度))/count(*)的区分度 来确定。
## 失效场景
- ** 【强制】页面搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决。 **
**场景一： ， **
说明：索引文件具有 B-Tree 的最左前缀匹配特性，如果左边的值未确定，那么无法使用此索 引。
使用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来代替，
- ** 【推荐】如果有 order by 的场景，
正例： ：
反例： ， ， ：
**场景二： ，
- ** 【推荐】利用覆盖索引来进行查询操作，避免回表。**
负向查询包括： < >、!< 、!>、NOT IN、NOT LIKE等。其实负向查询并不绝对会索引失效， ，
说明：如果一本书需要知道第 11 章是什么标题，会翻开第 11 章对应的那一页吗？目录浏览 一下就好，这个目录就是起到覆盖索引的作用。 正例：能够建立索引的种类分为主键索引、唯一索引、普通索引三种，而覆盖索引只是一种查 询的一种效果，用 explain 的结果， ：
- ** 【推荐】利用延迟关联或者子查询优化超多分页场景。**
说明：
**场景三： ， ，
- ** 【推荐】SQL 性能优化的目标：至少要达到 range 级别，要求是 ref 级别，如果可以是 consts 最好。**
其实单个索引字段， ，
说明：
1）
2） （ ）
**场景四：在索引列上使用内置函数，一定会导致索引失效**
3）
比如下面语句中索引列login_time上使用了函数， ：
```sql
select * from user where DATE_ADD(login_time, INTERVAL 1 DAY) = 7;
```
反例： ， ， ， ，
- ** 【推荐】建组合索引的时候，区分度最高的在最左边。**
正例：如果 where a=? and b=? ，如果 a 列的几乎接近于唯一值，那么只需要单建 idx_a 索引即可。
**场景五：隐式类型转换导致的索引失效**
如下面语句中索引列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+树，更新频繁的字段建立索引会大大降低数据库性能。
- “性别”这种区分度不大的属性，建立索引是没有什么意义的，不能有效过滤数据，性能与全表扫描类似。
- ** 建立组合索引，必须把区分度高的字段放在前面 **
ruyu.li
3 years ago