MySQL数据库—SQL优化

曾经终败给现在 2024-05-06 10:00 59阅读 0赞

## MySQL数据库—SQL优化 ##

**数据准备**

DROP TABLE IF EXISTS `employees`;
    CREATE TABLE `employees`  (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `name` varchar(24) NOT NULL,
      `age` int(11) NOT NULL,
      `position` varchar(20),
      `hire_time` timestamp(0) NOT NULL DEFAULT CURRENT_TIMESTAMP(0) ON UPDATE CURRENT_TIMESTAMP(0),
      PRIMARY KEY (`id`) 
    ) ENGINE = InnoDB AUTO_INCREMENT = 1 
    
    # 插入数据，这里插入十万条，可根据自己需要调整
    drop procedure if exists insert_emp;
    delimiter ;;
    create procedure insert_emp()
    begin
    	declare i int;
    	set i = 1;
    	while (i <= 100000) do
    		start transaction;
    		insert into employees (name,age,position) values(CONCAT('David',i),i,'dev');
    			set i=i+1;
    		end while;
    end;;
    delimiter ;
    call insert_emp();
    
    # 创建联合索引
    CREATE INDEX idx_name_age_position USING BTREE ON employees (name,age,`position`);
    
    # 小数据量表，表结构和employees相同
    CREATE TABLE `employees_copy`  (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `name` varchar(24) NOT NULL,
      `age` int(11) NOT NULL,
      `position` varchar(20),
      `hire_time` timestamp(0) NOT NULL DEFAULT CURRENT_TIMESTAMP(0) ON UPDATE CURRENT_TIMESTAMP(0),
      PRIMARY KEY (`id`) 
    ) ENGINE = InnoDB AUTO_INCREMENT = 1 
    
    insert into employees_copy values (1, 'David', 22, 'manager', '2024-03-30 17:53:26');
    insert into employees_copy values (2, 'Alice', 21, 'manager', '2024-03-30 17:53:26');
    insert into employees_copy values (3, 'Tom', 22, 'dev', '2024-03-30 17:53:26');
    insert into employees_copy values (4, 'Peter', 22, 'dev', '2024-03-30 17:53:26');
    insert into employees_copy values (5, 'Mark', 22, 'dev', '2024-03-30 17:53:26');
    
    CREATE INDEX idx_name_age_position USING BTREE ON employees_copy (name,age,`position`);
    
    # 小数据量表，用于测试非联合索引的索引使用情况
    CREATE TABLE `employees_copy2`  (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `name` varchar(24) DEFAULT NULL,
      `age` int(11) DEFAULT NULL,
      `position` varchar(20),
      `hire_time` timestamp(0) NOT NULL DEFAULT CURRENT_TIMESTAMP(0) ON UPDATE CURRENT_TIMESTAMP(0),
      PRIMARY KEY (`id`) 
    ) ENGINE = InnoDB AUTO_INCREMENT = 1 
    
    insert into employees_copy2 values (1, 'David', 22, 'manager', '2024-03-30 17:53:26');
    insert into employees_copy2 values (2, 'Alice', 21, 'manager', '2024-03-30 17:53:26');
    insert into employees_copy2 values (3, 'Tom', 22, 'dev', '2024-03-30 17:53:26');
    insert into employees_copy2 values (4, 'Peter', 22, 'dev', '2024-03-30 17:53:26');
    insert into employees_copy2 values (5, 'Mark', 22, 'dev', '2024-03-30 17:53:26');
    
    CREATE INDEX idx_name USING BTREE ON .employees_copy2 (name);

### 一、SQL优化的实践经验 ###

**1.尽量避免全表扫描，首先考虑在where或者order by涉及的列上建立索引**

**2.尽量避免在where子句中对字段进行null值和 not null值的判断**

select * from employees_copy2 where name is NULL;
    select * from employees_copy2 where name is NOT NULL;

**3.尽量避免在where子句中使用!=或<>操作符，会放弃使用索引进行全表扫描**

select * from employees_copy2 where name != "David" ;
    select * from employees_copy2 where name <> "David" ;

![在这里插入图片描述][c29f1d0edeba43f4b42123e8ee588717.png]  
**4.尽量避免在where子句使用函数运算等，会导致放弃使用索引进行全表扫描**

# 给age添加索引
    CREATE INDEX idx_age USING BTREE ON .employees_copy2 (age);
    # 对age字段进行运算
    explain select * from employees_copy2 where age/2 = 11;
    # 对name字段就行字符截取
    explain select * from employees_copy2 where SUBSTRING(name, 1, 2) = "avi" ;

![在这里插入图片描述][9af1e89748d742e4ab25aee9e8b7c4af.png]  
![在这里插入图片描述][08b3c7fcb477468bb2a24022c93a216d.png]

# 使用如下方式替换
    select * from employees_copy2 where age = 11 * 2
    select * from employees_copy2 where name like "avi%"

**5.尽量避免在where子句中使用or作为连接条件，如果一个字段有索引，另一个字段没有索引，会放弃使用索引进行全表扫描**

explain select * from employees_copy2 where name = "David" or age = 22

![在这里插入图片描述][09e74f5515024fa0a5dcc4bfb25c2c90.png]  
可以使用如下方式替换

explain select * from employees_copy2 where name = "David" union all select * from employees_copy2 where age = 22

![在这里插入图片描述][07df4aee5307465e8050b7d92e9d7981.png]

**6.联合索引第一个字段使用范围查询，可能不走索引**

explain select * from employees where name > "David" and age = 22 and `position` = "dev"

![在这里插入图片描述][516e533078084bb5b19dbf21ef563e7d.png]

**7.覆盖索引优化**

explain select name, age, `position` from employees where name > "David" and age = 22 and `position` = "dev"

![在这里插入图片描述][31fbfb6fd2654c7eba01ed4dbf65c0c0.png]  
**8.in在数据量比较大的时候会走索引，数据量不太多的时候会全表扫描**

# 数据量几十万
    explain select * from employees where name in ('David','Tom');

![在这里插入图片描述][40ef6885b4ba45f79e1aa3bdfa9e783c.png]

# 数据量很少
    explain select * from employees_copy where name in ('David','Tom');

![在这里插入图片描述][d488347fdd014ea598328aecf4d585d5.png]  
**9.对于连续的数值，使用between…and…替换in**

select * from employees_copy2 where id between 1 and 4

**10.能使用exists和not exists替代in和not in 就尽量使用exists和not exists**

*  比如两个表数据量几十万，不是很大，但是两个表关联查询使用not in 时，not in 不能命中索引，查询时间可能会几分钟甚至更久
 *  还有是容易出现问题（查询结果有误）。

create table test1 (id1 int);
    create table test2 (id2 int);
    
    insert into test1 values (1), (2), (3);
    insert into test2 values (1), (2);
    
    # 以上两个表，我现在想查询test2中存在的test1中的id
    # 使用in
    select id1 from test1 where id1 in (select id2 from test2);

![在这里插入图片描述][ec323c7efd7c4b728ebd44d64b636eda.png]

# 但是如果写错了SQL，如下
    select id1 from test1 where id1 in (select id1 from test2);

![在这里插入图片描述][bec8e5d538924f30afcb2ea093f522b8.png]  
结果并没有报错，单独查询select id1 from test2肯定会报错的。再看not in出问题的情况

# 在test2中插入一个空值
    insert into test2 values (null);
    # 查询test2中不存在test1的id的值
    select id1 from test1 where id1 is not in (select id2 from test2)

![在这里插入图片描述][272dae315fa54d25a8f675b20f6e3ef6.png]  
结果并不是我们预期的结果，结果应该为3。原因是null值不等于非空的值，test2没有空值的话会输出3，有了空值，3也不等于null，所以不会输出。

# 使用 not exsits
    select id1 from test1 where not exists (select 1 from test2 where id1 = id2)

![在这里插入图片描述][61ad1b5e65ec4579a2692099e938bfa7.png]  
**11.尽量不要使用like %KK%，这样也会放弃使用索引进行全表扫描**

explain select * from employees_copy2 where name like "%David%"

![在这里插入图片描述][7ff4179c0f3a471580060da72d571ad9.png]  
**12.like KK%一般都会走索引**

# 数据量几十万，此时并没有走索引，MySQL内部优化可能全表扫描更快，这里也有可能和数据有关系，我们的测试数据都是David*
    explain select * from employees where name like 'Tom%' and age = 22 and `position` = 'dev';

![在这里插入图片描述][01f42ea92ae84a998f811f04c52296d5.png]

# 数据量很少
    explain select * from employees_copy where name like 'David%' and age = 22 and `position` = 'dev';

![在这里插入图片描述][e46636a8387e48fd8703250de312fae6.png]

**PS： like KK%其实用到了索引下推优化**  
**索引下推**：正常按照索引最左前缀原则，上面的SQL只会走name字段索引，因为根据name字段过滤后，age和position字段是无序的，无法利用索引。MySQL5.6之前，这个查询匹配到”David“开头的索引，然后**先去拿主键回表，再找到相应的记录，对比age和position是否符合**。MySQL5.6之后，引入**索引下推优化，可以在索引遍历的过程中，对索引中包含的所有字段先做判断，过滤掉不符合条件的记录再回表，可以有效的减少回表次数**。对于innodb引擎的表**索引下推只能用于二级索引**，innodb的主键索引（聚簇索引）树叶子节点上保存的是全行数据，所以这个时候索引下推并不会起到减少查询全行数据的效果。

**13.order by 与 group by 深入优化**

# 最左前缀原则，中间字段不能断，查询使用了name索引，age索引优化再排序中，extra列没有using filesort
    EXPLAIN SELECT * from employees where name = 'David' and position = 'manager' order by age;

# 使用position排序，跳过了age，extra列出现了using filesort
    EXPLAIN SELECT * from employees where name = 'David' order by position;

# 使用age,position排序，extra列没有出现using filesort
    EXPLAIN SELECT * from employees where name = 'David' order by age,position;

# 虽然使用age,position排序，但是位置颠倒了，违背了最左原则，extra列出现了using filesort
    EXPLAIN SELECT * from employees where name = 'David' order by position,age;

# 使用age,position排序，虽然位置颠倒了，但是age是常量，在排序中被优化，没有出现using filesort
    EXPLAIN SELECT * from employees where name = 'David' and age =22 order by position,age;

# 默认升序，这里使用倒序，索引排序方式不同，出现using filesort，MySQL8.0以上版本有降序索引可支持这种方式
    EXPLAIN SELECT * from employees where name = 'David' order by age,position desc;

# 出现了using filesort，因为对于排序来说，多个相等条件也是范围查询
    EXPLAIN SELECT * from employees where name in ('David','Tom') order by age,position;

**小结**

1、MySQL支持filesort和index两种排序，using index是指MySQL扫描索引本身完成排序，index效率高，filesort效率低。

2、order by满足以下两种情况会使用using index

*  order by 使用索引最左原则
 *  使用where子句与order by子句条件组合满足索引最左原则

3、尽量在索引列完成排序，遵循索引最左原则

4、order by的条件不在索引列，会出现using filesort；

5、能使用覆盖索引尽量使用覆盖索引

6、group by是先排序后分组，遵循索引最左原则，对于group by不需要排序的后面加上order by null禁止排序

7、where高于having，能写在where的条件不要在having限定

### 二、using filesort排序原理 ###

**filesort文件排序方式**

*  单路排序：是一次性取出满足条件行的所有字段，然后在sortbuffer中进行排序；用trace工具可以看到sort\_mode信息里显示<sort\_key,additional\_fields>或者<sort\_key,packed\_additional\_fields>
 *  双路排序（又叫回表排序模式）：是首先根据相应的条件取出相应的排序字段和可以直接定位行数据的行ID，然后在sortbuffer中进行排序，排序完后需要再次取回其它需要的字段；用trace工具可以看到sort\_mode信息里显示<sort\_key,rowid>

MySQL通过比较系统变量max\_length\_for\_sort\_data(默认1024字节)的大小和需要查询的字段总大小来判断使用哪种排序模式。

*  如果字段的总长度小于max\_length\_for\_sort\_data，那么使用单路排序模式；
 *  如果字段的总长度大于max\_length\_for\_sort\_data，那么使用双路排序模∙式。

**单路排序的过程**

1、从索引name找到第一个满足name=‘David’条件的主键id

2、根据主键id取出整行，取出所有字段的值，存入sort\_buffer中

3、从索引name找到下一个满足name=‘David’条件的主键id

4、重复步骤2、3直到不满足name=‘David’

5、对sort\_buffer中的数据按照字段position进行排序

6、返回结果给客户端

**双路排序的过程**

1、从索引name找到第一个满足name=‘David’的主键id

2、根据主键id取出整行，把排序字段position和主键id这两个字段放到sortbuffer中

3、从索引name取下一个满足name=‘David’记录的主键id

4、重复3、4直到不满足name=‘David‘

5、对sort\_buffer中的字段position和主键id按照字段position进行排序

6、遍历排序好的id和字段position，按照id的值回到原表中取出所有字段的值返回给客户端

**两种排序方式比较：**

1、单路排序会把所有需要查询的字段都放到sortbuffer中，而双路排序只会把主键和需要排序的字段放到sortbuffer中进行排序，然后再通过主键回到原表查询需要的字段。

2、如果MySQL排序内存sort\_buffer配置的比较小并且没有条件继续增加了，可以适当把max\_length\_for\_sort\_data配置小点，让优化器选择使用双路排序算法，可以在sort\_buffer中一次排序更多的行，只是需要再根据主键回到原表取数据。

3、如果MySQL排序内存有条件可以配置比较大，可以适当增大max\_length\_for\_sort\_data的值，让优化器优先选择全字段排序(单路排序)，把需要的字段放到sort\_buffer中，这样排序后就会直接从内存里返回查询结果了。

4、MySQL通过max\_length\_for\_sort\_data这个参数来控制排序，在不同场景使用不同的排序模式，从而提升排序效率。

5、如果全部使用sort\_buffer内存排序一般情况下效率会高于磁盘文件排序，但不能因为这个就随便增大sort\_buffer(默认1M)，mysql很多参数设置都是做过优化的，不要轻易调整。

### 三、索引设计原则 ###

**1、代码先行，索引后上**  
一般应该等到主体业务功能开发完毕，把涉及到该表相关sql都要拿出来分析之后再建立索引。

**2、联合索引尽量覆盖条件**  
可以设计一个或者两三个联合索引(尽量少建单值索引)，让每一个联合索引都尽量去包含sql语句里的where、orderby、groupby的字段，还要确保这些联合索引的字段顺序尽量满足sql查询的最左前缀原则。

**3、不要在小基数字段上建立索引**  
一般建立索引，尽量使用那些基数比较大的字段，就是值比较多的字段，这才能体现出B+树查询的效率，比如性别字段，只有男女，建索引没有太大意义。

**4、长字符串采用前缀索引**  
比如varchar(255)的大字段可能会比较占用磁盘空间，可以稍微优化下，比如针对这个字段的前20个字符建立索引，类似于idx(name(20),age,position)。此时你在where条件里搜索的时候，如果是根据name字段来搜索，那么此时就会先到索引树里根据name字段的前20个字符去搜索，定位到之后前20个字符的前缀匹配的部分数据之后，再回到聚簇索引提取出来完整的name字段值进行比对。但是假如你要是order by name，那么此时你的name因为在索引树里仅仅包含了前20个字符，所以这个排序是没法用上索引的，group by也是同理。

**5、where与order by冲突时优先where**  
一般都是让where条件去使用索引来快速筛选出来一部分指定的数据，接着再进行排序操作。因为大多数情况基于索引进行where筛选往往可以最快速度筛选出你要的少部分数据，然后做排序的成本可能会小很多。

**6、基于慢SQL查询做优化**  
慢sql查询优化参考：[https://blog.csdn.net/qq\_40884473/article/details/89455740][https_blog.csdn.net_qq_40884473_article_details_89455740]

### 四、分页查询优化 ###

**1、自增且连续的主键排序的分页查询**

select * from employees limit 90000, 5;

# 执行计划
    explain select * from employees limit 90000, 5;

**使用主键**

select * from employees where id > 90000 limit 5;

# 执行计划
    explain select * from employees where id > 90000 limit 5;

结论：使用主键查询走了索引，扫描行数大大减少，效率高。

但是如果表中的记录被删了，主键空缺，结果会不一致，所以使用主键优化的查询SQL需满足下面两个条件：

*  主键自增且连续
 *  结果是按主键排序的

**2、根据非主键字段排序的分页查询**

select * from employees ORDER BY name limit 90000, 5;

explain select * from employees ORDER BY name limit 90000, 5;

– 没有使用索引name字段，原因是扫描整个索引并查找到没索引的行，可能要遍历多个索引树，成本比全表扫描的成本高，所以MySQL优化器放弃使用索引

**优化SQL**

select * from employees e inner join (select id from employees ORDER BY name limit 90000, 5) em on em.id = e.id;

explain select * from employees e inner join (select id from employees ORDER BY name limit 90000, 5) em on em.id = e.id;

### 五、join关联查询优化 ###

**MySQL关联表查询有两种算法**

*  Nested-LoopJoin算法
 *  BlockNested-LoopJoin算法

#### 1、嵌套循环连接Nested-LoopJoin(NLJ)算法 ####

一次一行循环地从第一张表（称为驱动表）中读取行，在这行数据中取到关联字段，根据关联字段在另一张表（被驱动表）里取出满足条件的行，然后取出两张表的结果合集。

EXPLAIN SELECT * FROM t1 inner join t2 on t1.a = t2.b;

![在这里插入图片描述][04201e1858fb49d9840f947ade8aef10.png]  
**从执行计划可以看到以下信息：**

1、驱动表是t2，被驱动表是t1。先执行的就是驱动表(执行计划结果的id如果一样则按从上到下顺序执行sql)；优化器一般会**优先选择小表做驱动表。所以使用inner join时，排在前面的表并不一定就是驱动表**。  
2、当使用left join时，左表是驱动表，右表是被驱动表，当使用right join时，右表时驱动表，左表是被驱动表，当使用join时，mysql会选择数据量比较小的表作为驱动表，大表作为被驱动表。  
3、使用了NLJ算法。一般join语句中，如果执行计划Extra中未出现Using join buffer则表示使用的join算法是NLJ。

**上面SQL的执行流程：**  
1、从表t2中读取一行数据（如果t2表有查询过滤条件的，会从过滤结果里取出一行数据）  
2、从第1步的数据中，取出关联字段a，到表t1中查找  
3、取出表t1中满足条件的行，跟t2中获取到的结果合并，作为结果返回给客户端  
4、重复上面三步

整个过程会读取t2表的所有数据(**扫描100行**)，然后遍历这每行数据中字段a的值，根据t2表中a的值索引扫描t1表中的对应行(**扫描100次t1表的索引，1次扫描可以认为最终只扫描t1表一行完整数据，也就是总共t1表也扫描了100行**)。因此**整个过程扫描了200行**。

如果被驱动表的关联字段**没索引**，**使用NLJ算法性能会比较低**，MySQL会选择Block Nested-Loop Join算法。

#### 2、基于块的嵌套循环连接Block Nested-Loop Join(BNL)算法 ####

把驱动表的数据读入到**join\_buffer**中，然后**扫描被驱动表**，把被驱动表每一行取出来跟join\_buffer中的数据做对比。

**Extra中的Usingjoinbuffer(Block NestedLoop)说明该关联查询使用的是BNL算法。**

EXPLAIN SELECT * FROM t1 inner join t2 on t1.a = t2.b;

![在这里插入图片描述][a1930e9a06cc47a9a6c1eff598b7483e.png]

**上面SQL的执行流程：**  
1、把t2的所有数据放入到join\_buffer中  
2、把表t1中每一行取出来，跟join\_buffer中的数据做对比  
3、返回满足join条件的数据

整个过程对表**t1和t2**都做了一次**全表扫描**，因此**扫描的总行数为10000**(表t1的数据总量)+100(表t2的数据总量)=10100。并且j**oin\_buffer里的数据是无序**的，因此对表t1中的每一行，都要做100次判断，所以内存中的**判断次数是100\*10000=100万次**。

这个例子里表t2才100行，要是表t2是一个大表，join\_buffer放不下怎么办呢？join\_buffer的**大小是由参数join\_buffer\_size**设定的，默认值是**256k**。如果放不下表t2的所有数据话，策略很简单，就是分段放。比如t2表有1000行记录，join\_buffer一次只能放800行数据，那么执行过程就是先往join\_buffer里放800行记录，然后从t1表里取数据跟join\_buffer中数据对比得到部分结果，然后清空join\_buffer，再放入t2表剩余200行记录，再次从t1表里取数据跟join\_buffer中数据对比。所以就**多扫了一次t1表**。

**被驱动表的关联字段没索引为什么要选择使用BNL算法而不使用Nested-LoopJoin？**  
如果上面第二条sql使用Nested-LoopJoin，那么扫描行数为100\*10000=100万次，这个是磁盘扫描。很显然，用BNL磁盘扫描次数少很多，相比于磁盘扫描，BNL的内存计算会快得多。因此MySQL对于被驱动表的关联字段没索引的关联查询，一般都会使用BNL算法。如果有索引一般选择NLJ算法，有索引的情况下NLJ算法比BNL算法性能更高.

#### 3、关联SQL的优化 ####

**关联字段加索引：MySQL做join操作时尽量选择NLJ算法**

**小表驱动大表：写多表连接SQL时如果明确知道哪张表是小表可以用straight\_join**写法固定连接驱动方式，省去MySQL优化器自己判断的过程

PS：straight\_join功能同join类似，但能让左边的表来驱动右边的表，能改表优化器对于联表查询的执行顺序。

# 指定MySQL选t2表作为驱动表
    select * from t2 straight_join 11 on t2.a = t1.b
    
    # straight_join只适用于inner join，left join和right join已经指定了顺序
    # 大部分情况下MySQL的优化器是比我们做得好的，所以一般情况下尽可能让优化器判断，我们无需干涉

#### 4、in和exsits优化 ####

**原则：小表驱动大表，即小的数据集驱动大的数据集**

in：当B表的数据集小于A表的数据集，in优于exists

select * from A where A.id in (select B.id from B);

exists：当A表的数据集小于B表的数据集，exists优于in

# 将主查询A的数据，放到子查询B中做条件验证，根据验证结果（true或false）来决定主查询的数据是否保留
    select * from A where exists (select 1 from B where B.id = A.id)

1、EXISTS(subquery)只返回TRUE或FALSE,因此子查询中的SELECT\*也可以用SELECT1替换,官方说法是实际执行时会忽略SELECT清单,因此没有区别

2、EXISTS子查询的实际执行过程可能经过了优化而不是我们理解上的逐条对比

3、EXISTS子查询往往也可以用JOIN来代替，何种最优需要具体问题具体分析

### 六、count(\*)查询优化 ###

explain select count(*) from employees;
    explain select count(1) from employees;
    explain select count(id) from employees;
    explain select count(name) from employees;

**count不会统计字段为null值的数据行**

四个SQL的执行效率差不多，可以看下四个SQL的执行计划是差不多的

字段有索引：count(※)≈count(1)>count(字段)>count(主键id)  
字段有索引，count(字段)统计走二级索引，二级索引存储数据比主键索引少，所以count(字段)>count(主键id)  
字段无索引：count(※)≈count(1)>count(主键id)>count(字段)  
字段无索引：count(字段)走不了索引，count(主键id)还可以走主键索引，所以count(主键id)>count(字段)，count(1)跟count(字段)执行过程类似，不过count(1)不需要取出字段统计，就用常量1做统计，count(字段)还需要取出字段，所以理论上count(1)比count(字段)会快一点。

count( \* )是例外，MySQL并不会把全部字段取出来，而是专门做了优化，不取值，按行累加，效率很高，所以不需要用count(列名)或count(常量)来替代count(\*)。为什么对于count(id)，MySQL最终选择辅助索引而不是主键聚集索引？因为二级索引相对主键索引存储数据更少，检索性能应该更高，MySQL内部做了点优化(应该是在5.7版本才优化)。

**常见优化方法**

1、查询MySQL自己维护的总行数  
对于myisam存储引擎的表做不带where条件的count查询性能是很高的，因为myisam存储引擎的表的总行数会被mysql存储在磁盘上，查询不需要计算。  
对于innodb存储引擎的表mysql不会存储表的总记录行数(因为有MVCC机制，后面会讲)，查询count需要实时计算。

2、show table status  
如果只需要知道表总行数的估计值可以用如下sql查询，性能很高

show table status like "employees";

3、将总数维护到Redis里  
插入或删除表数据行的时候同时维护redis里的表总行数key的计数值(用incr或decr命令)，但是这种方式可能不准，很难保证表操作和redis操作的事务一致性

4、增加数据库计数表  
插入或删除表数据行的时候同时维护计数表，让他们在同一个事务里操作

[c29f1d0edeba43f4b42123e8ee588717.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/34aab3f79a7644b0b976f6cf7c86be86.png
[9af1e89748d742e4ab25aee9e8b7c4af.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/d614017ea7904b9c9ddde906eda6b416.png
[08b3c7fcb477468bb2a24022c93a216d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/8e69678c25764f6585545e8e38e0101d.png
[09e74f5515024fa0a5dcc4bfb25c2c90.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/309ee6115d0f4b9ebb8340c4ce5b046e.png
[07df4aee5307465e8050b7d92e9d7981.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/e4b5b3160bcf4a2e899a22a8fcf917e7.png
[516e533078084bb5b19dbf21ef563e7d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/9d30a932a7414b7493ad0efca5e5f54a.png
[31fbfb6fd2654c7eba01ed4dbf65c0c0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/2ab6bd95f2624e9190e7902b38ddc42e.png
[40ef6885b4ba45f79e1aa3bdfa9e783c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/29654196a3984ab89e7a8d40e04d49a4.png
[d488347fdd014ea598328aecf4d585d5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/5e0471ae52fb4960960f6ef27b116e57.png
[ec323c7efd7c4b728ebd44d64b636eda.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/1cd9e84a743b40e49d3e53e55571b1f8.png
[bec8e5d538924f30afcb2ea093f522b8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/2f65e4bef9b34e2c8953f94a35ccdf89.png
[272dae315fa54d25a8f675b20f6e3ef6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/d2c442206f65433e97e94cbc76b29462.png
[61ad1b5e65ec4579a2692099e938bfa7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/d1e41e45b5b94a5e97ff1ad5994b3d39.png
[7ff4179c0f3a471580060da72d571ad9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/f28fa59d25e748db8e993899e2d8e12d.png
[01f42ea92ae84a998f811f04c52296d5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/cd208f1edd344f6280c18833cf9e846a.png
[e46636a8387e48fd8703250de312fae6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/e4451fef462544c3bc9ad12f9484cbbc.png
[https_blog.csdn.net_qq_40884473_article_details_89455740]: https://blog.csdn.net/qq_40884473/article/details/89455740
[04201e1858fb49d9840f947ade8aef10.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/d0f6d7e72fd64282b853a0c1ab196cb0.png
[a1930e9a06cc47a9a6c1eff598b7483e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/d85702eb66104d1a9327d9c84f461064.png