深入理解MySQL原理之三--如何实现事务与分库分表

柔情只为你懂 2022-11-09 14:25 320阅读 0赞

# 一、前言 #

MySQL有很多特性，其中事务和分库分表是我们开发过程常用到的，本章节我们重点介绍。我们将了解到：

1、事务有哪些特点，事务的隔离级别，开发过程中如何选择对应的级别?

2、事务是如何实现的，什么是行锁表锁以及版本控制?

3、分库分表的使用场景，以及实现方式和策略有哪些?

4、分库分表后存在哪些问题，如何解决这些问题?

# 二、事务 #

## 1、为什么要有事务 ##

账户A给账户B转款，处理流程如下:

(1)、A账户扣款m元

(2)、B账户收款m元

如果第一步完成后，第二步出错了，那么就会导致A账户款被扣了，但是B账户没有收到款。如果哪个的银行系统这么设计，那么就离关门不远了，当然还没听说银行因为这个倒闭，正是使用了"事务"。

"事务"是将这两步看成了一个整体，要么一起执行，要么一起不执行。如第二步出错后，整体回滚，那么A账户也不会扣钱。

实际开发过程中，我们经常删除主表以及相关联的扩展表数据，就需要使用事务，否则就容易造成脏数据。如要支持事务，需要选择Innodb引擎。

## 2、事务的要素 ##

要成为"事务"，需要符合以下几个要素，简称ACID。

(1)A(Atomicity),原子性，事务里面的所有操作，看成一个原子操作，要么一起做完，要么一起不做，不存在部分执行，部分没有执行的中间状态。上例中，扣款和收款就是一个原子操作。

(2)C(Consistency),一致性，事务开始前和结束后，数据库的完整性约束没有被破坏，上例中，不能出现A扣了钱，但是B没有收到。

(3)I(Isolation),独立性，事务之间是互相独立的，隔离的，不允许相互影响，上例中，A账户扣钱完成前，其他账户不能向A账户充钱。

(4)D(Durability),持久化，事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。上例中，一旦完成转款并提交，A账户的钱就要不回来了，投资有风险，转款需谨慎。

## 3、事务的隔离级别 ##

事务的独立性要求事务之间有隔离的，隔离也分4个级别，每个级别对应不同的要求。

*  read-uncommitted(读未提交)，隔离级别最低的，A事务中的任何修改，在未提交的情况下，都暴露给B事务，相当于裸奔。
 *  read-committied(读提交，又称不可重复读，RC)，A事务的任何修改，只有在提交的情况下，B事务才能感知到。
 *  repeatable-read(可重复读，RR)，A事务做了修改，并且提交，B事务如果在其修改前启动的，那么在B事务内，读到的是修改前的数据，不会感知到A的修改，直到B事务结束。MySQL的默认级别。
 *  serializable(串行化)，隔离级别最高的，将事务的执行变为顺序执行，就相当于单线程，A事务执行过程中，B阻塞，直到A提交。

这几个级别按照直译后的字面含义，很难理解是什么意思。没关系，接下来我们用实例演示下这四个级别的区别。

先了解下几个操作指令：

*  查看当前的隔离级别，MySQL8.0版本之前，select @@tx\_isolation，MySQL8.0版本之后，select @@transaction\_isolation;
 *  设置隔离级别，SET \[SESSION | GLOBAL\] TRANSACTION ISOLATION LEVEL \{READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE\}。 GLOBAL 是全局的，而 SESSION 只针对当前回话窗口。隔离级别是 \{READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE\} 这四种，不区分大小写。比如： set global transaction isolation level read committed 。
 *  事务开始， 以 begin 或者 start transaction 开始。
 *  事务结束，以commit或者rollback结束。

先创建一张表user，其中userid为主键，username字段建立普通索引。

CREATE TABLE `user` (
      `userid` int(11) NOT NULL,
      `username` varchar(45) DEFAULT NULL,
      `useraccount` varchar(45) DEFAULT NULL,
      `money` int(11) DEFAULT NULL,
      PRIMARY KEY (`userid`),
      KEY `index_username` (`username`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

接下来我们插入一些数据

![20210316102910770.png][]

### (1)read-uncommitted(读未提交) ###

打开两个客户端，模拟事务A和B。

1)启动事务A，并修改money数据，暂不提交。

#--事务A---
    set  session transaction isolation level read uncommitted;
    start transaction;#启动事务
    update world.user  set money=500 where userid=4;

2)启动事务B，查询该条数据。

#--事务B---
    set  session transaction isolation level read uncommitted;
    start transaction;#启动事务
    SELECT * FROM world.user a where a.userid=4;

查询到的结果如下，B事务可以看到修改后的值了。

![20210316104236194.png][]

所以，对于read-uncommittied级别，A修改后未提交，其他事务也能看到修改后的值。

### (2)read-committied(读提交) ###

我们将数据重置到初始状态，继续往下

1)启动事务A，并修改money数据，暂不提交

#--事务A---
    set  session transaction isolation level read committed;
    start transaction;#启动事务
    update world.user  set money=500 where userid=4;

2)启动事务B，查询该条数据

set  session transaction isolation level read committed;
    start transaction;#启动事务
    SELECT * FROM world.user a where a.userid=4;

查询到的结果如下，B事务无法看到修改后的值。

![20210316105545832.png][]

3)A事务提交后，重新执行B事务查询

#--事务A---
    commit;

#--事务B---
    SELECT * FROM world.user a where a.userid=4;

查询结果如下：

![20210316110108819.png][]

所以，对于read-committied级别，A事务修改后，未提交，B事务无法查询到更新值，A事务提交后，B事务可以查看。

### (3)repeatable-read(可重复读) ###

将数据重置到初始状态，继续往下

1) 启动事务A，并修改数据，暂不提交

#--事务A---
    set  session transaction isolation level  repeatable read;
    start transaction;#启动事务
    update world.user  set money=500 where userid=4;

2)启动事务B，查询该条数据

#--事务B---
    set  session transaction isolation level   repeatable read;
    start transaction;#启动事务
    #--事务B---
    SELECT * FROM world.user a where a.userid=4;

查询到的结果如下，B事务无法看到修改后的值。

![20210316111425796.png][]

3)A事务提交后，重新执行B事务查询

#--事务A---
    commit;

#--事务B---
    SELECT * FROM world.user a where a.userid=4;

查询结果如下：

![20210316111425796.png][]

对于repeatable-read级别，A事务提交后，B事务查到的还是之前的数据。也就是说，B事务结束前，查询到的都是B事务开始时的数据"快照"。

### (4)serializable(串行化) ###

将数据重置到初始状态，继续往下

1)启动事务A，并修改数据，暂不提交

#--事务A---
    set  session transaction isolation level serializable;
    start transaction;#启动事务
    update world.user  set money=500 where userid=4;

2)启动事务B，查询该条数据

#--事务B---
    set  session transaction isolation level  serializable;
    start transaction;#启动事务
    #--事务B---
    SELECT * FROM world.user a where a.userid=4;

此时，B事务阻塞住了。

![20210316112312719.png][]

3)提交A事务

#--事务A---
    commit;

此时，B事务可以执行了，查询到修改后的值。

![20210316112721265.png][]

对于serializable级别，A事务执行时，其他事务处于排队阻塞状态(包括读事务)，当A事务提交后，才开始其他事务执行。

需要注意的是，对于以上的隔离级别，都是针对与"读"的,即A事务更新，B事务读的场景。如果A，B事务都对于同一条记录进行修改，那么B事务必定会阻塞。我们来验证下，将隔离级别调整到最低read uncommitted进行测试。

(1)启动A事务，并修改数据，暂不提交

#--事务A---
    set  session transaction isolation level  read uncommitted;
    start transaction;#启动事务
    update world.user  set money=500 where userid=4;

(2)启动B事务，并修改同一条数据

#--事务B---
    set  session transaction isolation level   read uncommitted;
    start transaction;#启动事务
    #--事务B---
    update world.user  set money=600 where userid=4;

此时B事务是阻塞的

![20210316160623597.png][]

(3)A事务提交，B事务执行

![20210316160743969.png][]

## 4、事务级别对并发问题的解决 ##

先看下并发的相关问题。

**脏读**，事务未提交，其他事务就可以感知到，一旦该事务回滚，那么其他事务感知到的就是脏数据。

**不可重复读**，其他事务修改了某个记录并提交，在另外的事务中，对该条记录多次读，会导致结果不一致。

**幻读：**幻读主要是针对**插入**操作，很多同学对这个有些困惑，下面我们就重点通过实例演示下幻读现象。

(1)设置为repeatable read级别，A事务将所有的money字段更新为600

#--事务A---
    set  session transaction isolation level  repeatable read;
    start transaction;#启动事务
    update world.user set money=600;

(2)此时，A事务尚未提交，B事务插入一条记录

set  session transaction isolation level   repeatable read;
    start transaction;#启动事务
    #--事务B---
    insert world.user values(5,'胡七','huqi',300);

(3)A事务再提交后，B事务再提交，A再查看记录

![20210319115647502.png][]

新插入的记录，并没有修改。

作为A来说，不知道更新后还有新记录插入，认为所有的数据都已经修改才对，这条异常数据是个"幻觉"，所以称之为"幻读"。解决"幻读"问题，仅能通过设置serializable级别。

各隔离级别对并发问题的支持如下：

<table style="width:500px;"> 
 <tbody> 
  <tr> 
   <td style="width:201px;"></td> 
   <td style="width:108px;">脏读</td> 
   <td style="width:129px;">不可重复读</td> 
   <td>幻读</td> 
  </tr> 
  <tr> 
   <td style="width:201px;">read-uncommitted(读未提交)</td> 
   <td style="width:108px;">是</td> 
   <td style="width:129px;">是</td> 
   <td>是</td> 
  </tr> 
  <tr> 
   <td style="width:201px;">read-committed(读提交)</td> 
   <td style="width:108px;">否</td> 
   <td style="width:129px;">是</td> 
   <td>是</td> 
  </tr> 
  <tr> 
   <td style="width:201px;">repeatable-read(可重复读)</td> 
   <td style="width:108px;">否</td> 
   <td style="width:129px;">否</td> 
   <td>是</td> 
  </tr> 
  <tr> 
   <td style="width:201px;">serializable(串行化)</td> 
   <td style="width:108px;">否</td> 
   <td style="width:129px;">否</td> 
   <td>否</td> 
  </tr> 
 </tbody> 
</table>

对于事务的级别，MySQL默认为RR基本满足绝大部分场景要求了。对于解决幻读，可以使用应用层的分布式锁解决。

## 5、事务的原理 ##

MySQL对于事务的管控主要通过设置隔离级别实现，那么底层是如何实现这些隔离级别的呢。

其实，实现原理也不难想到，我们在做应用开发的时候也遇到过很多并发的问题，一般都是使用"锁"来解决，乐观锁，悲观锁，共享锁等等，锁的作用就是将宏观上并行的问题，在微观上利用串行解决。

对于MySQL也不例外，锁的类型很多，这里我们重点介绍下常用的行锁和表锁。

### (1)行锁 ###

顾名思义，行锁就是以行为粒度进行加锁，我们用实例来看下行锁的实现

1)A事务更新userid=5行记录，暂不提交

set  session transaction isolation level  repeatable read;
    start transaction;#启动事务
    update world.user set useraccount='hq1' where userid=5;

2)新开一个客户端窗口，模拟其他事务也更新这行记录

update world.user set useraccount='hq2' where userid=5;

此时处于阻塞状态

![2021032511315389.png][]

我们再更新一个其他行的记录

update world.user set useraccount='ml1' where userid=4;

可以正确执行

![20210325154058612.png][]

由此可见，只是锁住了userid=5这一条记录。

下面我们看下多行记录的情况

1)A事务更新userid>1 and userid<4的多行记录,暂未提交

#--事务A---
    set  session transaction isolation level  repeatable read;
    start transaction;#启动事务
    update world.user set money=300 where userid>1 and userid<4;

2)新开一个客户端窗口，模拟其他事务也更新userid=1记录

update world.user set money=400 where userid=1;

结果如下：

![20210325155858678.png][]

正确执行，符合预期，A事务中更新并没有包含userid=1。

3)继续更新userid=4记录

update world.user set money=400 where userid=4;

结果如下：

![20210325160233908.png][]

阻塞住了，A事务明明是userid<4,为什么将userid=4也锁住了呢，在MySQL中，行锁的范围是左开右闭，也就是(1,4\]。为什么这样？行锁并不是在这条记录上加锁，而是在索引上加锁。

![20210325161040110.png][]

这种锁也成为**间隙锁**，**所有的行锁仅针对索引加锁，包括主键，唯一索引，普通索引**。

### (2)表锁 ###

表锁就是以表为粒度进行加锁。上面说了行锁仅对索引加锁，那我们选择一个非索引列(money)作为查询条件看下

1)A事务更新(条件为money=300)，暂未提交

#--事务A---
    set  session transaction isolation level  repeatable read;
    start transaction;#启动事务
    update world.user set useraccount='test' where money=300;

2))新开一个客户端窗口，更新money=400记录

update world.user set useraccount='test2' where money=400;

结果为

![20210325163340968.png][]

可以看到，阻塞住了，对于条件为非索引列的更新，是用表锁实现的。

需要注意的是，当行锁的数量达到一定阀值，行锁会逐级升级为页锁和表锁。

我们来总结下：

**(1)行锁的粒度比表锁的小，锁冲突的概率也小，尽量使用行锁。**

**(2)正确的加索引，使用主键或者索引加锁，避免引起全表扫描，导致锁表。**

## 6、MVCC(多版本控制) ##

上面的行锁和表锁解决了"写-写"冲突问题，对于"读-写"来说，从严格意义上，也可以使用悲观锁控制，但是考虑到实际场景和性能要求，大多数情况下是不需要类似"写-写"那么严格的，无需加锁。

前面我们在讲到repeatable-read隔离级别时，提到了"快照"，这个就是MySQL解决无锁状态下"读-写"冲突的方式，那是怎么做到的呢？

我们使用git提交版本后 ，可以根据根据版本号回溯到之前的任意版本。实际上，MySQL也是用了这个方式，称之为MVCC(多版本控制)。

MVCC原理就是每条记录增加隐藏字段，保存事务号，每次事务对记录的改变，保存一条记录，用链表将这些历史记录串起来。当事务A读某个记录，利用最新记录做了快照(该记录的最新事务号)，A事务内部读取该记录，使用记录的事务号，到链表中找到对应的记录，其表象就是做了一份快照。A事务的读操作，不会影响其他事务的写，同样，其他事务的写，也不会影响A事务的读。

当然，MVCC实现过程要比这个复杂，还需要考虑到历史记录的老化等，这方面的文章也比较多，我们也会在[深入理解MySQL原理之五--InnoDB存储引擎][MySQL_--InnoDB]中具体介绍。

# 三、分库分表 #

对于一些流水型的数据，包括交易记录，日志记录，评论记录等等，都是随着系统运行的时间快速增长，当数据量达到一定度，IO,CPU,网络都会是瓶颈，数据库的整体性能将下降，甚至带来灾难性后果。此时有几种常用的方法：

(1)、提升硬件性能，增加CPU核数，使用高速网卡，简单粗暴，成本高，对于整体性能的改善也是有限的。

(2)、冷热数据库分离，定期将不活跃的数据移到冷库中，热库中仅保留访问量高的活跃数据。这种对于冷热界限比较明显的数据比较合适的，比如交易型数据，但是对于用户型数据就不大合适，今天的不活跃用户不代表未来不活跃。

(3)、分库分表，这个也是我们最常用方式，将库和表拆成多个，也是我们今天重点讨论的内容。

## 1、为什么要分库分表 ##

前面也说了一部分，当数据量达到一定程度，会导致IO,CPU,网络成为瓶颈。我们具体来看：

(1)当一张表的数据量特别大(上亿条)，全量扫描的时间会更长，如果发生锁表，影响事务的并发，另外B+索引维护也是一份巨大的工作，这些都会导致CPU飙升。

(2)当一个库的数据特别大，MySQL是半工型的，网络带宽影响数据的传输，导致查询的性能下降，另外也会产生大量的IO，降低查询速度。

反过来，如果实现了分库分表，有什么好处:

(1)最重要的是，我们说的这些瓶颈都不存在，且对于单个库表的维护简单很多，量变导致质变。

(2)这些库表分布在不同的物理设备上，可以有效利用这些设备的性能。

当然分库分表也会导致很多问题，比如事务一致性，夸库的操作，包括join，排序等等，后面我们也将逐个分析。

## 2、如何分库分表 ##

可以分为垂直拆分和水平拆分。

### (1)垂直拆分 ###

**1)垂直分库**，以业务的维度，将表分到不同的库中，比如用户库，订单库等。每个库的表结构不一样，数据也没有交集。

对于垂直分库的场景，一般是结合业务系统的分拆，特别是对于微服务的架构，这种情况会比较多。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70][]

**2)垂直分表，**以业务的维度，将字段拆分到不同的表中，比如将表拆成主表和扩展表，通过主键关联。

对于垂直分表的场景，一般是对于宽表(字段比较多)，可以按照活跃字段以及非活跃字段进行拆表，但是也要考虑一部分字段冗余(反范式)，避免大量的join。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 1][]

### (2)水平拆分 ###

**1)水平分库，**以字段为依据，按照某种策略(hash,rang等)，将库中的数据分拆到多个库中。每个库中的表结构是一样，所有数据的并集就是全量数据。

对于水平分拆的场景，在高并发情况下，将网络，cpu，io的压力负载到多个分库上。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 2][]

**2)水平分表**，以字段为依据，按照某种策略(hash,rang等)，将一张表中的数据分拆到多张表，每张表的结构一样的，所有数据的并集就是全量数据。

对于水平分表的场景，一张表的数据太多(大于500w行)，影响SQL的执行效率，数据分拆到多张表中，减轻CPU的压力。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 3][]

### 3)水平分库分表的策略 ###

常用的有以下几种策略：

**HASH**

以某个字段进行hash，将数据均衡的分布到分库和分表上。一般适用于一些离散型的字段，比如会员号，账号等。

**Range**

按照范围进行分割，比如以价格，年龄等。

**时间**

按照时间范围，这种对于操作日志，流水记录的库表比较适合。

**地区**

按照地区进行分割，这种对于地区强相关的数据比较适合，比如天气记录。

## 3、分库分表需要注意的问题 ##

分库分表是整个数据库设计中最复杂的环节之一，在实践过程中需要考虑因素很多，而且这些如果处理不好，会导致后续变更非常困难。

下面我们就来梳理下这些问题

### (1)跨库查询的问题 ###

当所有的表都在同一个库中，我们可以"随心所欲"的去join，但是分库之后，问题就来了，比如我们分割为用户库和订单库，现在需要根据用户名查询用户订单，首先需要根据用户名查到到用户的账号，然后根据账号查询订单。**不要试图做夸库的join**，我们看下都有哪些解决方法。

![20210331100041385.png][]

**1)应用层join**

这个应该是首先想到的方法，先查询用户表，获取到用户id，然后再将用户id作为入参查询订单库，获取最终结果。这种方式需要依靠应用层的逻辑处理，对于比较复杂的场景，需要多次查询，并进行条件过滤才能得到最终的结果。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 4][]

**2)冗余法**

将订单表在用户库中也保存一份，这个就可以在同一个库中join了。这种方式看起来与分库原则向违背，实际上是常用的方式，特别对于强关联的表做冗余，用空间换效率。

![20210331144813420.png][]

对于一些字典表，也常用此种方法。

**3)索引法**

和冗余发有些类似，只不过不是将整张表冗余，而是将对应关系的字段保存在相关库中，比如

![20210331145029352.png][]

对于水平分库，按照某个属性字段进行拆分所有表，尽量将查询封闭到一个库中。

### (2)扩容迁移的问题 ###

对于按照范围，时间和区域的水平拆分策略，可以直接扩容，不涉及迁移的问题，而对于hash取模扩容的时候则需要考虑原数据的迁移。

比如原有两个库A,B,策略为：userid%2==0->A，userid%2==1->B

现在需要扩容一倍，新增C,D两个库，策略为userid%4==0->A,userid%4==1->B.userid%4==2->C,userid%4==3->D

有以下几种方案

**1)停服扩容**

首先禁止写，然后通过脚本将A，B两个库的数据按照规则重新导入到新库。这也是最简单粗暴的方式，一般对于业务影响不大的库。

**2)数据迁移**

通过迁移工具，将A，B的库数据按照规则迁移到B,D,找个业务低峰期，禁止一段时间的写入，待A,B的数据排干，再切换到新的策略。该方案会影响一段时间的业务，大部分情况下是可接受的。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 5][]

**3)主从同步**

C库作为A库的从库，D库作为B库的从库，首先进行主从复制，C，D分别同步全量的A，B库的数据，再切换策略，生效后，断开复制关系。这种方式无需停机，与数据迁移相比较，C,D库中会有冗余的数据。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 6][]

### (3)聚合，排序，分页，分组的问题 ###

一旦分库了，那么聚合，排序，分页，分组都面临了多个库操作的问题，比如说订单按照用户id的维度分布到各个库中，现在要按照时间进行降序，就需要在每个库查询记录，然后在内存中排序，再返回客户端。如果应用来实现，将是非常复杂的，幸运的是，有一些开源的组件帮我们完成。这里推荐两款：

**1）Sharing-JDBC**

Sharding-JDBC是当当网的开源中间件，属于客户端模式，支持分库分表、读写分离、分布式 id 生成、柔性事务。sharding-jdbc无需单独部署，维护简单，对于规模不大，轻量级应用较适合。

**2)Mycat**

Mycat是目前国内比较活跃的数据中间件，与sharding-jdbc不同的是，它采用的是proxy模式，支持分库分表，读写分离，分片策略配置，自动路由，分布式事务，多租户等特性，功能非常强大。由于需要单独部署，维护较为复杂，开发人员需要对此有一定了解，所以一般适合一些大型的数据库集群上使用。

### (4)夸库事务的问题 ###

分库后，事务的一致性就无法保证，比如用户下单时，生成订单和库存扣减需要在一个事务中，当订单和库存在一个库中，没有问题，但是当订单和库存分库后，现有的机制就无法保证了。

目前解决方案是分布式(XA)事务，采用的二阶段提交方式，包括:

prepare(准备)

commit/rollback(提交/回滚)

XA分布式事务模型定义了事务管理器(TM,常见的是交易中间件),资源管理器(RM，一般是数据库)，

成功的流程如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 7][]

失败的流程如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 8][]

分布式事务需要所有的RM反馈后才能提交，如果哪个RM处理速度慢，整个事务只能处于等待状态，直到timeout，在高并发情况下，严重影响性能。

在5.7.7版本前，分布式事务存在bug，一些情况下会导致主从数据不一致。所以最好选择使用5.7.7之后的版本。

# 四、总结 #

回答开篇的几个问题作为总结：

**Q:事务有哪些特点，事务的隔离级别，开发过程中如何选择对应的级别?**

**A**:(1)事务的特点包括：A(原子性)C(一致性)I(独立性)D(持久性)

(2)隔离级别包括：read-uncommitted(读未提交)，read-committied(读提交，又称不可重复读，RC)，repeatable-read(可重复读，RR)，serializable(串行化)，级别越高，要求越严格。

(3)如没有特殊要求，RR级别满足大部分场景，也是MySQL的默认级别。串行化不推荐使用，一般在应用层实现分布式锁解决。

**Q:事务是如何实现的，什么是行锁表锁以及版本控制?**

**A：**事务是通过各种锁实现的，其中最重要的是**行锁**和**表锁，**行锁是以行记录为粒度进行加锁，行锁仅针对索引列(包括主键，唯一索引，普通索引)，表锁是以表为粒度进行加锁，针对普通列。

版本控制是以更新的事务号作为"版本号"，以链表的方式保存该行的历史记录，事务可以通过事务号回溯到记录"快照"，解决"读-写"冲突。

**Q:分库分表的使用场景，以及实现方式和策略有哪些?**

**A:**当数据量达到一定程度，会严重影响数据库的读写性能，分库分表是常用的解决方式之一，由分为水平和垂直拆分两种方式。对于水平拆分，又可以按Hash，Range，时间，地区等策略。

**Q:分库分表后存在哪些问题，如何解决这些问题?**

**A:**主要总结了跨库查询，扩容迁移，聚合，分页排序，分组，以及跨库事务的问题。

对于跨库查询，主要有应用层join，冗余法，索引法几种处理方法。

对于扩容迁移，主要有停服扩容，数据迁移，主从同步方法。

聚合，分页排序，分组，可以使用数据库中间件解决。

跨库事务采用分布式事务，数据库中间件也提供了相关的解决方案。

附：

[深入理解MySQL原理之一--如何提升查询SQL的性能][MySQL_--_SQL]

[深入理解MySQL原理之二--如何建立高效索引][MySQL_--]

[深入理解MySQL原理之三--如何实现事务与分库分表][MySQL_-- 1]

[深入理解MySQL原理之四--如何实现高可用][MySQL_-- 2]

[深入理解MySQL原理之五--如何高效利用InnoDB存储引擎][MySQL_--InnoDB]

[深入理解MySQL原理之六--核心算法有哪些][MySQL_-- 3]

[深入理解MySQL原理之七--云原生时代将何去何从][MySQL_-- 4]

[20210316102910770.png]: /images/20221023/9ba7e601e4f643a68fd40b7ada451d11.png
[20210316104236194.png]: /images/20221023/c1d4d93f68784e0485f7dd4b1fc6c511.png
[20210316105545832.png]: /images/20221023/2885bd0b820d4d7b90526785352778a8.png
[20210316110108819.png]: /images/20221023/ea0be23f572049c79842c7862019c1db.png
[20210316111425796.png]: /images/20221023/e5ee618e101c4b3ba8c4cd02f40429ab.png
[20210316112312719.png]: /images/20221023/7896534e69534874bc1ac87176f58a91.png
[20210316112721265.png]: /images/20221023/a82138417d034f4ca44171e4d04befb6.png
[20210316160623597.png]: /images/20221023/20edb2ece8b74b3ca017aead4f3fa0a5.png
[20210316160743969.png]: /images/20221023/c956d6511f7b4fafa937565b2914c40e.png
[20210319115647502.png]: /images/20221023/eea438ecb1ec4faaa18361ddaaa70706.png
[2021032511315389.png]: /images/20221023/460eb381ed7e456e90798fba2c039cbc.png
[20210325154058612.png]: /images/20221023/b69b97145ffe415492d3e52f84098f14.png
[20210325155858678.png]: /images/20221023/7822e6491a144d7287adad6a4d9b9e86.png
[20210325160233908.png]: /images/20221023/e9f5c94b423841d5877ce4b0049a674d.png
[20210325161040110.png]: /images/20221023/d834a24dded5474b8b492c9636c0083a.png
[20210325163340968.png]: /images/20221023/b2b18b257e3e4565a35a92847cd049e0.png
[MySQL_--InnoDB]: https://blog.csdn.net/tcy83/article/details/117407724
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70]: /images/20221023/01eda7e9146c41058afad58c3947eb9c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 1]: /images/20221023/a67e5020d0604fd6a10bac6eae3c2df2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 2]: /images/20221023/604fb1e48db24289aa495a2c8472a1ed.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 3]: /images/20221023/42a2263a56e74f38aa07943cbf274c8f.png
[20210331100041385.png]: /images/20221023/341ae8d4da004a5ab6f39af56451646b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 4]: /images/20221023/adee0a4cd3d14bf8b4a3aefceb3fe611.png
[20210331144813420.png]: /images/20221023/51c64580514240f48065b492fed5304d.png
[20210331145029352.png]: /images/20221023/0233f807f7cf430dbdb20b181403be7f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 5]: /images/20221023/9eb5d7ed7ce14cd49cbb2a3d2095c355.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 6]: /images/20221023/b295313266ad4a42b07297913b26aa12.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 7]: /images/20221023/788760a637054bb6979017c367aafed6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 8]: /images/20221023/a889229cbdae4f39963f44b4b3f022c0.png
[MySQL_--_SQL]: https://blog.csdn.net/tcy83/article/details/108546004
[MySQL_--]: https://blog.csdn.net/tcy83/article/details/114048168
[MySQL_-- 1]: https://blog.csdn.net/tcy83/article/details/114848104
[MySQL_-- 2]: https://blog.csdn.net/tcy83/article/details/115453583
[MySQL_-- 3]: https://blog.csdn.net/tcy83/article/details/117918385
[MySQL_-- 4]: https://blog.csdn.net/tcy83/article/details/119088747