【MySql】12- 实践篇(十)

文章目录

    • 1. 为什么临时表可以重名?
      • 1.1 临时表的特性
      • 1.2 临时表的应用
      • 1.3 为什么临时表可以重名?
      • 1.4 临时表和主备复制
    • 2. MySql内部临时表使用场景
      • 2.1 union 执行流程
      • 2.2 group by 执行流程
      • 2.3 group by 优化方法 -- 索引
      • 2.4 group by 优化方法 -- 直接排序
    • 3. Memory引擎
      • 3.1 内存表的数据组织结构
      • 3.2 hash 索引和 B-Tree 索引
      • 3.3 内存表的锁
      • 3.4 数据持久性问题

1. 为什么临时表可以重名?

在优化 join 查询的时候使用到了临时表。当时是这么用的:

create temporary table temp_t like t1;
alter table temp_t add index(b);
insert into temp_t select * from t2 where b>=1 and b<=2000;
select * from t1 join temp_t on (t1.b=temp_t.b);

临时表有哪些特征,为什么它适合这个场景?

临时表和内存表的区别

  • 内存表,指的是使用 Memory 引擎的表,建表语法是 create table … engine=memory。这种表的数据都保存在内存里,系统重启的时候会被清空,但是表结构还在。除了这两个特性看上去比较“奇怪”外,从其他的特征上看,它就是一个正常的表。

  • 临时表,可以使用各种引擎类型 。如果是使用 InnoDB 引擎或者 MyISAM 引擎的临时表,写数据的时候是写到磁盘上的。当然,临时表也可以使用 Memory 引擎。

1.1 临时表的特性

图 1 临时表特性示例
图 1 临时表特性示例
可以看到,临时表在使用上有以下几个特点:

  1. 建表语法是 create temporary table …。
  2. 一个临时表只能被创建它的 session 访问,对其他线程不可见。所以,图中 session A 创建的临时表 t,对于 session B 就是不可见的。
  3. 临时表可以与普通表同名。
  4. session A 内有同名的临时表和普通表的时候,show create 语句,以及增删改查语句访问的是临时表。
  5. show tables 命令不显示临时表。

由于临时表只能被创建它的 session 访问,所以在这个 session 结束的时候,会自动删除临时表。也正是由于这个特性,临时表就特别适合我们文章开头的 join 优化这种场景。原因如下:

  1. 不同 session 的临时表是可以重名的,如果有多个 session 同时执行 join 优化,不需要担心表名重复导致建表失败的问题。
  2. 不需要担心数据删除问题。如果使用普通表,在流程执行过程中客户端发生了异常断开,或者数据库发生异常重启,还需要专门来清理中间过程中生成的数据表。而临时表由于会自动回收,所以不需要这个额外的操作。

1.2 临时表的应用

不用担心线程之间的重名冲突,临时表经常会被用在复杂查询的优化过程中。其中,分库分表系统的跨库查询就是一个典型的使用场景。

一般分库分表的场景,就是要把一个逻辑上的大表分散到不同的数据库实例上。

比如。将一个大表 ht,按照字段 f,拆分成 1024 个分表,然后分布到 32 个数据库实例上。如下图所示:
图 2 分库分表简图
图 2 分库分表简图
一般情况下,这种分库分表系统都有一个中间层 proxy。不过,也有一些方案会让客户端直接连接数据库,也就是没有 proxy 这一层。在这个架构中,分区 key 的选择是以“减少跨库和跨表查询”为依据的。

如果大部分的语句都会包含 f 的等值条件,那么就要用 f 做分区键。这样,在 proxy 这一层解析完 SQL 语句以后,就能确定将这条语句路由到哪个分表做查询。

比如下面这条语句:

select v from ht where f=N;

可以通过分表规则(比如,N%1024) 来确认需要的数据被放在了哪个分表上。这种语句只需要访问一个分表,是分库分表方案最欢迎的语句形式了。

但是,如果这个表上还有另外一个索引 k,并且查询语句是这样的:

select v from ht where k >= M order by t_modified desc limit 100;

由于查询条件里面没有用到分区字段 f,只能到所有的分区中去查找满足条件的所有行,然后统一做 order by 的操作。

这种情况下,有两种比较常用的思路。

  • 第一种思路是,在 proxy 层的进程代码中实现排序。
    优点:处理速度快,拿到分库的数据以后,直接在内存中参与计算
    缺点:

    1. 需要的开发工作量比较大。举例的这条语句还算是比较简单的,如果涉及到复杂的操作,比如 group by,甚至 join 这样的操作,对中间层的开发能力要求比较高;
    2. 对 proxy 端的压力比较大,尤其是很容易出现内存不够用和 CPU 瓶颈的问题。
  • 第二种思路就是,把各个分库拿到的数据,汇总到一个 MySQL 实例的一个表中,然后在这个汇总实例上做逻辑操作。

比如上面这条语句,执行流程可以类似这样:

  • 在汇总库上创建一个临时表 temp_ht,表里包含三个字段 v、k、t_modified;
  • 在各个分库上执行select v,k,t_modified from ht_x where k >= M order by t_modified desc limit 100;
  • 把分库执行的结果插入到 temp_ht 表中;
  • 执行select v from temp_ht order by t_modified desc limit 100;

得到结果。
过程对应的流程图如下所示:

图 3 跨库查询流程示意图
图 3 跨库查询流程示意图
在实践中,往往会发现每个分库的计算量都不饱和,所以会直接把临时表 temp_ht 放到 32 个分库中的某一个上。

1.3 为什么临时表可以重名?

在执行create temporary table temp_t(id int primary key)engine=innodb;语句的时候,MySQL 要给这个 InnoDB 表创建一个 frm 文件保存表结构定义,还要有地方保存表数据。

这个 frm 文件放在临时文件目录下,文件名的后缀是.frm,前缀是“#sql{进程 id}{线程 id} 序列号”。可以使用 select @@tmpdir 命令,来显示实例的临时文件目录。

关于表中数据的存放方式,在不同的 MySQL 版本中有着不同的处理方式:

  • 在 5.6 以及之前的版本里,MySQL 会在临时文件目录下创建一个相同前缀、以.ibd 为后缀的文件,用来存放数据文件;
  • 从 5.7 版本开始,MySQL 引入了一个临时文件表空间,专门用来存放临时文件的数据。因此,就不需要再创建 ibd 文件了。

可以看到,其实创建一个叫作 t1 的 InnoDB 临时表,MySQL 在存储上认为我们创建的表名跟普通表 t1 是不同的,因此同一个库下面已经有普通表 t1 的情况下,还是可以再创建一个临时表 t1 的。

举例

图 4 临时表的表名
图 4 临时表的表名
这个进程的进程号是 1234,session A 的线程 id 是 4,session B 的线程 id 是 5。可以看到,session A 和 session B 创建的临时表,在磁盘上的文件不会重名。

MySQL 维护数据表,除了物理上要有文件外,内存里面也有一套机制区别不同的表,每个表都对应一个 table_def_key。

  • 一个普通表的 table_def_key 的值是由“库名 + 表名”得到的,所以如果你要在同一个库下创建两个同名的普通表,创建第二个表的过程中就会发现 table_def_key 已经存在了。
  • 对于临时表,table_def_key 在“库名 + 表名”基础上,又加入了“server_id+thread_id”。

session A 和 sessionB 创建的两个临时表 t1,它们的 table_def_key 不同,磁盘文件名也不同,因此可以并存。

实现上,每个线程都维护了自己的临时表链表。这样每次 session 内操作表的时候,先遍历链表,检查是否有这个名字的临时表,如果有就优先操作临时表,如果没有再操作普通表;在 session 结束的时候,对链表里的每个临时表,执行 “DROP TEMPORARY TABLE + 表名”操作。


1.4 临时表和主备复制

binlog 中也记录了 DROP TEMPORARY TABLE 这条命令。临时表只在线程内自己可以访问,为什么需要写到 binlog 里面?

既然写 binlog,就意味着备库需要。

设想一下,在主库上执行下面这个语句序列:

create table t_normal(id int primary key, c int)engine=innodb;/*Q1*/
create temporary table temp_t like t_normal;/*Q2*/
insert into temp_t values(1,1);/*Q3*/
insert into t_normal select * from temp_t;/*Q4*/

如果关于临时表的操作都不记录,那么在备库就只有 create table t_normal 表和 insert into t_normal select * from temp_t 这两个语句的 binlog 日志,备库在执行到 insert into t_normal 的时候,就会报错“表 temp_t 不存在”。

如果把 binlog 设置为 row 格式,因为 binlog 是 row 格式时,在记录 insert into t_normal 的 binlog 时,记录的是这个操作的数据,即:write_row event 里面记录的逻辑是“插入一行数据(1,1)”。如果当前的 binlog_format=row,那么跟临时表有关的语句,就不会记录到 binlog 里。也就是说,只在 binlog_format=statment/mixed 的时候,binlog 中才会记录临时表的操作。

这种情况下,创建临时表的语句会传到备库执行,因此备库的同步线程就会创建这个临时表。主库在线程退出的时候,会自动删除临时表,但是备库同步线程是持续在运行的。所以,这时候我们就需要在主库上再写一个 DROP TEMPORARY TABLE 传给备库执行。

问题 1
MySQL 在记录 binlog 的时候,不论是 create table 还是 alter table 语句,都是原样记录,甚至于连空格都不变,但是如果执行 drop table t_normal,系统记录 binlog 就会写成:DROP TABLE t_normal /* generated by server */ 也就是改成了标准的格式。为什么要这么做呢 ?

drop table 命令是可以一次删除多个表的。比如,在上面的例子中,设置 binlog_format=row,如果主库上执行 "drop table t_normal, temp_t"这个命令,那么 binlog 中就只能记录:DROP TABLE t_normal /* generated by server */ 因为备库上并没有表 temp_t,将这个命令重写后再传到备库执行,才不会导致备库同步线程停止。

所以,drop table 命令记录 binlog 的时候,就必须对语句做改写。“/* generated by server */”说明了这是一个被服务端改写过的命令。

问题 2
主库上不同的线程创建同名的临时表是没关系的,但是传到备库执行是怎么处理的呢?

下面的序列中实例 S 是 M 的备库
图 5 主备关系中的临时表操作
主库 M 上的两个 session 创建了同名的临时表 t1,这两个 create temporary table t1 语句都会被传到备库 S 上。

但是,备库的应用日志线程是共用的,也就是说要在应用线程里面先后执行这个 create 语句两次。(即使开了多线程复制,也可能被分配到从库的同一个 worker 中执行)。这会不会导致同步线程报错 ?

显然是不会。
MySQL 在记录 binlog 的时候,会把主库执行这个语句的线程 id 写到 binlog 中。这样,在备库的应用线程就能够知道执行每个语句的主库线程 id,并利用这个线程 id 来构造临时表的 table_def_key:

  1. session A 的临时表 t1,在备库的 table_def_key 就是:库名 +t1+“M 的 serverid”+“session A 的 thread_id”;
  2. session B 的临时表 t1,在备库的 table_def_key 就是 :库名 +t1+“M 的 serverid”+“session B 的 thread_id”。

由于 table_def_key 不同,所以这两个表在备库的应用线程里面是不会冲突的。


小结
在实际应用中,临时表一般用于处理比较复杂的计算逻辑。由于临时表是每个线程自己可见的,所以不需要考虑多个线程执行同一个处理逻辑时,临时表的重名问题。在线程退出的时候,临时表也能自动删除,省去了收尾和异常处理的工作。

在 binlog_format='row’的时候,临时表的操作不记录到 binlog 中,也省去了不少麻烦,这也可以成为选择 binlog_format 时的一个考虑因素。

需要注意的是,上面说到的这种临时表,是用户自己创建的 ,也可以称为用户临时表。与它相对应的,就是内部临时表


思考
下面的语句序列是创建一个临时表,并将其改名:

图 6 关于临时表改名的思考题
图 6 关于临时表改名的思考题
可以使用 alter table 语法修改临时表的表名,而不能使用 rename 语法。这是为什么?

执行 rename table 语句的时候,要求按照“库名 / 表名.frm”的规则去磁盘找文件,但是临时表在磁盘上的 frm 文件是放在 tmpdir 目录下的,并且文件名的规则是“#sql{进程 id}{线程 id} 序列号.frm”,因此会报“找不到文件名”的错误。


2. MySql内部临时表使用场景

2.1 union 执行流程

表 t1 来举例

create table t1(id int primary key, a int, b int, index(a));
delimiter ;;
create procedure idata()
begindeclare i int;set i=1;while(i<=1000)doinsert into t1 values(i, i, i);set i=i+1;end while;
end;;
delimiter ;
call idata();

执行下面这条语句:

(select 1000 as f) union (select id from t1 order by id desc limit 2);

这条语句用到了 union,它的语义是,取这两个子查询结果的并集。并集的意思就是这两个集合加起来,重复的行只保留一行。

语句的 explain 结果

图 1 union 语句 explain 结果
图 1 union 语句 explain 结果可以看到:

  • 第二行的 key=PRIMARY,说明第二个子句用到了索引 id。
  • 第三行的 Extra 字段,表示在对子查询的结果集做 union 的时候,使用了临时表 (Using temporary)。

语句的执行流程是这样的:

  1. 创建一个内存临时表,这个临时表只有一个整型字段 f,并且 f 是主键字段。
  2. 执行第一个子查询,得到 1000 这个值,并存入临时表中。
  3. 执行第二个子查询:
    • 拿到第一行 id=1000,试图插入临时表中。但由于 1000 这个值已经存在于临时表了,违反了唯一性约束,所以插入失败,然后继续执行;
    • 取到第二行 id=999,插入临时表成功。
  4. 从临时表中按行取出数据,返回结果,并删除临时表,结果中包含两行数据分别是 1000 和 999。

图 2 union 执行流程
图 2 union 执行流程

这里的内存临时表起到了暂存数据的作用,而且计算过程还用上了临时表主键 id 的唯一性约束,实现了 union 的语义。

如果把上面这个语句中的 union 改成 union all 的话,就没有了“去重”的语义。这样执行的时候,就依次执行子查询,得到的结果直接作为结果集的一部分,发给客户端。因此也就不需要临时表了。

图 3 union all 的 explain 结果
图 3 union all 的 explain 结果
第二行的 Extra 字段显示的是 Using index,表示只使用了覆盖索引,没有用临时表了。

2.2 group by 执行流程

另外一个常见的使用临时表的例子是 group by

select id%10 as m, count(*) as c from t1 group by m;

这个语句的逻辑是把表 t1 里的数据,按照 id%10 进行分组统计,并按照 m 的结果排序后输出。它的 explain 结果如下:

图 4 group by 的 explain 结果
图 4 group by 的 explain 结果
可以看到:

  • Using index,表示这个语句使用了覆盖索引,选择了索引 a,不需要回表;
  • Using temporary,表示使用了临时表;
  • Using filesort,表示需要排序。

执行流程:

  1. 创建内存临时表,表里有两个字段 m 和 c,主键是 m;
  2. 扫描表 t1 的索引 a,依次取出叶子节点上的 id 值,计算 id%10 的结果,记为 x;
    • 如果临时表中没有主键为 x 的行,就插入一个记录 (x,1);
    • 如果表中有主键为 x 的行,就将 x 这一行的 c 值加 1;
  3. 遍历完成后,再根据字段 m 做排序,得到结果集返回给客户端。

执行图如下:

图 5 group by 执行流程
图 5 group by 执行流程
图中最后一步,对内存临时表的排序,如下图
图 6 内存临时表排序流程

临时表的排序过程就是图 6 中虚线框内的过程。

图 7 group by 执行结果
图 7 group by 执行结果
如果需求并不需要对结果进行排序,那可以在 SQL 语句末尾增加 order by null,也就是改成:

select id%10 as m, count(*) as c from t1 group by m order by null;

这样就跳过了最后排序的阶段,直接从临时表中取数据返回。返回的结果如图 8 所示。

图 8 group + order by null 的结果(内存临时表)
图 8 group + order by null 的结果(内存临时表)

由于表 t1 中的 id 值是从 1 开始的,因此返回的结果集中第一行是 id=1;扫描到 id=10 的时候才插入 m=0 这一行,因此结果集里最后一行才是 m=0。

这个例子里由于临时表只有 10 行,内存可以放得下,因此全程只使用了内存临时表。但是,内存临时表的大小是有限制的,参数 tmp_table_size 就是控制这个内存大小的,默认是 16M。

如果执行下面这个语句序列:

set tmp_table_size=1024;
select id%100 as m, count(*) as c from t1 group by m order by null limit 10;

把内存临时表的大小限制为最大 1024 字节,并把语句改成 id % 100,这样返回结果里有 100 行数据。但是,这时的内存临时表大小不够存下这 100 行数据,也就是说,执行过程中会发现内存临时表大小到达了上限(1024 字节)。这时候就会把内存临时表转成磁盘临时表,磁盘临时表默认使用的引擎是 InnoDB。

返回的结果如图所示:
在这里插入图片描述
如果这个表 t1 的数据量很大,很可能这个查询需要的磁盘临时表就会占用大量的磁盘空间

2.3 group by 优化方法 – 索引

可以看到,不论是使用内存临时表还是磁盘临时表,group by 逻辑都需要构造一个带唯一索引的表,执行代价都是比较高的。如果表的数据量比较大,上面这个 group by 语句执行起来就会很慢,有什么优化的方法呢?

问题: 执行 group by 语句为什么需要临时表?

group by 的语义逻辑,是统计不同的值出现的个数。但是,由于每一行的 id%100 的结果是无序的,就需要有一个临时表,来记录并统计结果。如果扫描过程中可以保证出现的数据是有序的就可以实现快速排序

现在有一个类似图 10 的这么一个数据结构

图 10 group by 算法优化 - 有序输入
图 10 group by 算法优化 - 有序输入
如果可以确保输入的数据是有序的,那么计算 group by 的时候,就只需要从左到右,顺序扫描,依次累加。也就是下面这个过程:

  • 当碰到第一个 1 的时候,已经知道累积了 X 个 0,结果集里的第一行就是 (0,X);
  • 当碰到第一个 2 的时候,已经知道累积了 Y 个 1,结果集里的第二行就是 (1,Y);

按照这个逻辑执行的话,扫描到整个输入的数据结束,就可以拿到 group by 的结果,不需要临时表,也不需要再额外排序。

在 MySQL 5.7 版本支持了 generated column 机制,用来实现列数据的关联更新。可以用下面的方法创建一个列 z,然后在 z 列上创建一个索引(如果是 MySQL 5.6 及之前的版本,你也可以创建普通列和索引,来解决这个问题)。

alter table t1 add column z int generated always as(id % 100), add index(z);

这样,索引 z 上的数据就是类似图 10 这样有序的了。上面的 group by 语句就可以改成:

select z, count(*) as c from t1 group by z;

优化后的 group by 语句的 explain 结果,如下图所示:

图 11 group by 优化的 explain 结果
图 11 group by 优化的 explain 结果
从 Extra 字段可以看到,这个语句的执行不再需要临时表,也不需要排序了。

2.4 group by 优化方法 – 直接排序

如果碰上不适合创建索引的场景,还是要老老实实做排序的。那么,这时候的 group by 要怎么优化呢?

MySQL 有没有走磁盘临时表的方法?

在 group by 语句中加入 SQL_BIG_RESULT 这个提示(hint),就可以告诉优化器:这个语句涉及的数据量很大,请直接用磁盘临时表。

MySQL 的优化器一看,磁盘临时表是 B+ 树存储,存储效率不如数组来得高。所以,既然告诉了数据量很大,那从磁盘空间考虑,还是直接用数组来存吧。

select SQL_BIG_RESULT id%100 as m, count(*) as c from t1 group by m;

执行流程如下:

  1. 初始化 sort_buffer,确定放入一个整型字段,记为 m;
  2. 扫描表 t1 的索引 a,依次取出里面的 id 值, 将 id%100 的值存入 sort_buffer 中;
  3. 扫描完成后,对 sort_buffer 的字段 m 做排序(如果 sort_buffer 内存不够用,就会利用磁盘临时文件辅助排序);
  4. 排序完成后,就得到了一个有序数组。

两张图分别是执行流程图和执行 explain 命令得到的结果

图 12 使用 SQL_BIG_RESULT 的执行流程图
图 12 使用 SQL_BIG_RESULT 的执行流程图

图 13 使用 SQL_BIG_RESULT 的 explain 结果
图 13 使用 SQL_BIG_RESULT 的 explain 结果
从 Extra 字段可以看到,这个语句的执行没有再使用临时表,而是直接用了排序算法。

MySQL 什么时候会使用内部临时表?

  1. 如果语句执行过程可以一边读数据,一边直接得到结果,是不需要额外内存的,否则就需要额外的内存,来保存中间结果;
  2. join_buffer 是无序数组,sort_buffer 是有序数组,临时表是二维表结构;
  3. 如果执行逻辑需要用到二维表特性,就会优先考虑使用临时表。比如例子中,union 需要用到唯一索引约束, group by 还需要用到另外一个字段来存累积计数。

小结
重点讲了 group by 的几种实现算法,从中可以总结一些使用的指导原则:

  1. 如果对 group by 语句的结果没有排序要求,要在语句后面加 order by null;
  2. 尽量让 group by 过程用上表的索引,确认方法是 explain 结果里没有 Using temporary 和 Using filesort;
  3. 如果 group by 需要统计的数据量不大,尽量只使用内存临时表;也可以通过适当调大 tmp_table_size 参数,来避免用到磁盘临时表;
  4. 如果数据量实在太大,使用 SQL_BIG_RESULT 这个提示,来告诉优化器直接使用排序算法得到 group by 的结果。

思考
文章中图 8 和图 9 都是 order by null,为什么图 8 的返回结果里面,0 是在结果集的最后一行,而图 9 的结果里面,0 是在结果集的第一行?

答案见下节3. Memory引擎正文


3. Memory引擎

3.1 内存表的数据组织结构

假设有以下的两张表 t1 和 t2,其中表 t1 使用 Memory 引擎, 表 t2 使用 InnoDB 引擎。

create table t1(id int primary key, c int) engine=Memory;
create table t2(id int primary key, c int) engine=innodb;
insert into t1 values(1,1),(2,2),(3,3),(4,4),(5,5),(6,6),(7,7),(8,8),(9,9),(0,0);
insert into t2 values(1,1),(2,2),(3,3),(4,4),(5,5),(6,6),(7,7),(8,8),(9,9),(0,0);

分别执行 select * from t1 和 select * from t2。
图 1 两个查询结果 -0 的位置
图 1 两个查询结果 -0 的位置
可以看到,内存表 t1 的返回结果里面 0 在最后一行,而 InnoDB 表 t2 的返回结果里 0 在第一行。

表 t2 用的是 InnoDB 引擎,它的主键索引 id 的组织方式:InnoDB 表的数据就放在主键索引树上,主键索引是 B+ 树。所以表 t2 的数据组织方式如下图所示:

图 2 表 t2 的数据组织
图 2 表 t2 的数据组织与 InnoDB 引擎不同,Memory 引擎的数据和索引是分开的。看一下表 t1 中的数据内容

图 3 表 t1 的数据组织
图 3 表 t1 的数据组织
可以看到,内存表的数据部分以数组的方式单独存放,而主键 id 索引里,存的是每个数据的位置。主键 id 是 hash 索引,可以看到索引上的 key 并不是有序的。

在内存表 t1 中,当我执行 select * 的时候,走的是全表扫描,也就是顺序扫描这个数组。因此,0 就是最后一个被读到,并放入结果集的数据。

可见,InnoDB 和 Memory 引擎的数据组织方式是不同的:

  • InnoDB 引擎把数据放在主键索引上,其他索引上保存的是主键 id。这种方式,称之为索引组织表(Index Organizied Table)。
  • Memory 引擎采用的是把数据单独存放,索引上保存数据位置的数据组织形式,我们称之为堆组织表(Heap Organizied Table)。

这两个引擎的一些典型不同:

  1. InnoDB 表的数据总是有序存放的,而内存表的数据就是按照写入顺序存放的;
  2. 当数据文件有空洞的时候,InnoDB 表在插入新数据的时候,为了保证数据有序性,只能在固定的位置写入新值,而内存表找到空位就可以插入新值;
  3. 数据位置发生变化的时候,InnoDB 表只需要修改主键索引,而内存表需要修改所有索引;
  4. InnoDB 表用主键索引查询时需要走一次索引查找,用普通索引查询的时候,需要走两次索引查找。而内存表没有这个区别,所有索引的“地位”都是相同的。
  5. InnoDB 支持变长数据类型,不同记录的长度可能不同;内存表不支持 Blob 和 Text 字段,并且即使定义了 varchar(N),实际也当作 char(N),也就是固定长度字符串来存储,因此内存表的每行数据长度相同。

由于内存表的这些特性,每个数据行被删除以后,空出的这个位置都可以被接下来要插入的数据复用

比如,如果要在表 t1 中执行:

delete from t1 where id=5;
insert into t1 values(10,10);
select * from t1;

看到返回结果里,id=10 这一行出现在 id=4 之后,也就是原来 id=5 这行数据的位置。

需要指出的是,表 t1 的这个主键索引是哈希索引,因此如果执行范围查询,比如

select * from t1 where id<5;

是用不上主键索引的,需要走全表扫描。

3.2 hash 索引和 B-Tree 索引

内存表也是支持 B-Tree 索引的。在 id 列上创建一个 B-Tree 索引,SQL 语句可以这么写:

alter table t1 add index a_btree_index using btree (id);

这时,表 t1 的数据组织形式就变成了这样:

图 4 表 t1 的数据组织 – 增加 B-Tree 索引
图 4 表 t1 的数据组织 -- 增加 B-Tree 索引
新增 B-Tree 索引跟 InnoDB 的 b+ 树索引组织形式类似。
看一下这下面这两个语句的输出:

图 5 使用 B-Tree 和 hash 索引查询返回结果对比
图 5 使用 B-Tree 和 hash 索引查询返回结果对比
执行 select * from t1 where id<5 的时候,优化器会选择 B-Tree 索引,所以返回结果是 0 到 4。 使用 force index 强行使用主键 id 这个索引,id=0 这一行就在结果集的最末尾了。

一般在我们的印象中,内存表的优势是速度快,其中的一个原因就是 Memory 引擎支持 hash 索引。当然,更重要的原因是,内存表的所有数据都保存在内存,而内存的读写速度总是比磁盘快。

但是不建议在生产环境上使用内存表。这里的原因主要包括两个方面:

  1. 锁粒度问题;
  2. 数据持久化问题。

3.3 内存表的锁

内存表不支持行锁,只支持表锁。因此,一张表只要有更新,就会堵住其他所有在这个表上的读写操作。
注意的是,这里的表锁跟之前我们介绍过的 MDL 锁不同,但都是表级的锁。

图 6 内存表的表锁 – 复现步骤
图 6 内存表的表锁 -- 复现步骤
session A 的 update 语句要执行 50 秒,在这个语句执行期间 session B 的查询会进入锁等待状态。session C 的 show processlist 结果输出如下:

图 7 内存表的表锁 – 结果
图 7 内存表的表锁 -- 结果
跟行锁比起来,表锁对并发访问的支持不够好。所以,内存表的锁粒度问题,决定了它在处理并发事务的时候,性能也不会太好。

3.4 数据持久性问题

数据放在内存中,是内存表的优势,但也是一个劣势。因为,数据库重启的时候,所有的内存表都会被清空。

如果数据库异常重启,内存表被清空也就清空了,不会有什么问题。但是,在高可用架构下,内存表的这个特点简直可以当做 bug 来看待了

先看看 M-S 架构下,使用内存表存在的问题。

图 8 M-S 基本架构
图 8 M-S 基本架构
看一下下面这个时序:

  1. 业务正常访问主库;
  2. 备库硬件升级,备库重启,内存表 t1 内容被清空;
  3. 备库重启后,客户端发送一条 update 语句,修改表 t1 的数据行,这时备库应用线程就会报错“找不到要更新的行”。

这样就会导致主备同步停止。当然,如果这时候发生主备切换的话,客户端会看到,表 t1 的数据“丢失”了。

在图 8 中这种有 proxy 的架构里,大家默认主备切换的逻辑是由数据库系统自己维护的。这样对客户端来说,就是“网络断开,重连之后,发现内存表数据丢失了”。
由于 MySQL 知道重启之后,内存表的数据会丢失。所以,担心主库重启之后,出现主备不一致,MySQL 在实现上做了这样一件事儿:在数据库重启之后,往 binlog 里面写入一行 DELETE FROM t1。

如果使用是如图 9 所示的双 M 结构的话:

图 9 双 M 结构
图 9 双 M 结构
在备库重启的时候,备库 binlog 里的 delete 语句就会传到主库,然后把主库内存表的内容删除。这样在使用的时候就会发现,主库的内存表数据突然被清空了。

基于上面的分析,内存表并不适合在生产环境上作为普通数据表使用。

  1. 如果你的表更新量大,那么并发度是一个很重要的参考指标,InnoDB 支持行锁,并发度比内存表好;
  2. 能放到内存表的数据量都不大。如果你考虑的是读的性能,一个读 QPS 很高并且数据量不大的表,即使是使用 InnoDB,数据也是都会缓存在 InnoDB Buffer Pool 里的。因此,使用 InnoDB 表的读性能也不会差。

**建议你把普通内存表都用 InnoDB 表来代替。**但是,有一个场景却是例外的。在数据量可控,不会耗费过多内存的情况下,可以考虑使用内存表。

内存临时表刚好可以无视内存表的两个不足,主要是下面的三个原因:

  1. 临时表不会被其他线程访问,没有并发性的问题;
  2. 临时表重启后也是需要删除的,清空数据这个问题不存在;
  3. 备库的临时表也不会影响主库的用户线程。

小结
由于重启会丢数据,如果一个备库重启,会导致主备同步线程停止;如果主库跟这个备库是双 M 架构,还可能导致主库的内存表数据被删掉。
因此,在生产上,不建议使用普通内存表。

如果你是 DBA,可以在建表的审核系统中增加这类规则,要求业务改用 InnoDB 表。我们在文中也分析了,其实 InnoDB 表性能还不错,而且数据安全也有保障。而内存表由于不支持行锁,更新语句会阻塞查询,性能也未必就如想象中那么好。

基于内存表的特性,我们还分析了它的一个适用场景,就是内存临时表。


思考
假设你刚刚接手的一个数据库上,真的发现了一个内存表。备库重启之后肯定是会导致备库的内存表数据被清空,进而导致主备同步停止。这时,最好的做法是将它修改成 InnoDB 引擎表。假设当时的业务场景暂时不允许你修改引擎,你可以加上什么自动化逻辑,来避免主备同步停止呢?

假设的是主库暂时不能修改引擎,那么就把备库的内存表引擎先都改成 InnoDB。对于每个内存表,执行

set sql_log_bin=off;
alter table tbl_name engine=innodb;

这样就能避免备库重启的时候,数据丢失的问题。

由于主库重启后,会往 binlog 里面写“delete from tbl_name”,这个命令传到备库,备库的同名的表数据也会被清空。

因此,就不会出现主备同步停止的问题。

如果由于主库异常重启,触发了 HA,这时候我们之前修改过引擎的备库变成了主库。而原来的主库变成了新备库,在新备库上把所有的内存表(这时候表里没数据)都改成 InnoDB 表。

所以,如果我们不能直接修改主库上的表引擎,可以配置一个自动巡检的工具,在备库上发现内存表就把引擎改了。

同时,跟业务开发同学约定好建表规则,避免创建新的内存表。


来自林晓斌《MySql实战45讲》

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/144542.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

【第2章 Node.js基础】2.7 Node.js 的流(一)可写流

&#x1f308;可写流 &#x1f680;什么是可写流 可写流是对数据被写入的目的地的一种抽象。 所有可写流都实现了 stream.Writable类定义的接口。 可写流的例子包括&#xff0c;也都是实现了可写流接口的双工流 客户端的 HTTP 请求、服务器的HTTP 响应、fs 的写入流、zlib…

Android Jetpack的组件介绍,常见组件解析

jetpack组件有哪些 Android Jetpack是一个集成Android应用程序组件的一站式解决方案。它使开发人员能够专注于他们的应用程序的真正创新部分&#xff0c;而不会受到Android平台特定的限制。Jetpack组件可分为四个类别&#xff1a; 架构组件&#xff08;Architecture Componen…

从流程优化到经营提效,法大大电子签全面助力智慧零售升级

在新零售模式下&#xff0c;“商业综合体、百货商场、连锁商超、连锁便利店、线上电商平台”等各类商业零售企业借助数字化的手段来改造和重塑传统零售流程和逻辑&#xff0c;实现全面数字化转型&#xff0c;包括线上线下一体化、全场景覆盖、全链条联通、全渠道经营、客户服务…

【ASP.NET】Hello World

文章目录 1. 几个概念2. 搭建开发环境2.1 .NET SDK2.2 IDE & Editor 3 First Project3.1 步骤3.2 模板3.3 项目结构3.4 请求的处理流程 Reference Link 1. 几个概念 .NET 是一个平台&#xff0c;包括 .NET Framework、.NET Core、ASP.NET、C#等&#xff0c;可以构建桌面、W…

【python】Django——连接mysql数据库

笔记为自我总结整理的学习笔记&#xff0c;若有错误欢迎指出哟~ 【Django专栏】 Django——django简介、django安装、创建项目、快速上手 Django——templates模板、静态文件、django模板语法、请求和响应 Django——连接mysql数据库 Django——连接mysql数据库 连接MySQL数据库…

2023双十一爆冷收场,订单后暗藏这些电商痛点问题需要注意

打开某软件的瞬间&#xff0c;手不小心抖一下就进入了淘宝&#xff0c;而且无法第一时间准确找到关闭按钮。相信不少人都在这个双十一通过开屏广告为淘宝“贡献”至“超8亿”的访问量&#xff0c;更有网友辣评&#xff1a;“现在打开别的软件跳转淘宝的速度都比直接打开淘宝要快…

基于STM32婴儿床检测控制系统及源程序

一、系统方案 1、本设计采用STM32单片机作为主控器。 2、DHT11检测湿度&#xff0c;液晶OLED显示&#xff0c;声音检测声音&#xff0c;有声音或尿床&#xff0c;蜂鸣器报警。 3、手机APP可以控制音乐播放。 二、硬件设计 原理图如下&#xff1a; 三、单片机软件设计 1、首先…

新能源充电桩物联网应用之工业4G路由器

新能源充电桩是智慧城市建设中不可缺少且可持续发展的重要设施&#xff0c;而工业4G路由器物联网应用为其提供了更加高效、智能、实时的管理方式。充电桩通过工业4G路由器可以与充电运营商的管理中心建立稳定的连接&#xff0c;实现双向数据传输&#xff0c;为用户提供优质的充…

CMA认证和CNAS认可的联系和区别?哪个更权威?

一、CMA认证是什么?   CMA认证是指中国计量认证&#xff0c;省级以上的计量行政部门根据中国计量法的规定&#xff0c;对申请CMA测试资质的第三方检测机构进行评估&#xff0c;对检测水平和检测可靠性达到国家标准的实验室授予计量认证合格证书(CMA资质)。 二、CNAS认可是什…

有向无权图的最短路径

在运筹学领域的经典模型中&#xff0c;最大流问题、多商品网络流问题和最短路径问题等都依附在图上对问题进行描述&#xff0c;同样&#xff0c;当我们梳理问题的数学模型&#xff0c;或理解相关问题的求解算法时&#xff0c;也要依靠它。因此&#xff0c;我将总结和图相关的问…

Mac笔记本打开Outlook提示:您需要最新的版本的Outlook才能使用此数据库

Mac笔记本打开Outlook提示&#xff1a;您需要最新的版本的Outlook才能使用此数据库 故障现象&#xff1a; 卸载旧的office安装新版的office&#xff0c;打开outlook提示&#xff1a;您需要最新的版本的outlook才能使用此数据库。 故障截图&#xff1a; 故障原因&#xff1a;…

让文字在盒子中水平居中与垂直居中

简单方法&#xff1a; 1.先用text-align: center;将文字垂直居中。 2.再用line-height: Xpx;将元素的行高设置为与父元素同样的高度。&#xff08;这里的X代表父元素的高度&#xff09; 举例&#xff1a; 对于该网页的代码如下&#xff1a; <!DOCTYPE html> <html&…

AI中文版怎么用,版本分享,GPT官网入口

网页版上线啦&#xff0c;在线助力大学生、上班族的高效生活&#xff01; GPT4.0是OpenAI最新推出的聊天模型&#xff0c;它的语言理解和生成能力比以前的版本更强大。对于忙碌的上班族来说&#xff0c;GPT4.0能帮助你高效处理工作中的大部分写作任务&#xff0c;比如撰写报告…

Docker与VM虚拟机的区别以及Docker的特点

01、本质上的区别 VM(VMware)在宿主机器、宿主机器操作系统的基础上创建虚拟层、虚拟化的操作系统、虚拟化的仓库&#xff0c;然后再安装应用&#xff1b; Container(Docker容器)&#xff0c;在宿主机器、宿主机器操作系统上创建Docker引擎&#xff0c;在引擎的基础上再安装应…

【MySQL】索引和事务(B树、B+树图解原理)

一、索引 1.1 什么是索引&#xff1f; 索引是一种特殊的文件&#xff0c;包含着对数据表里所有记录的引用指针。可以对表中的一列或多列创建索引&#xff0c;并指定索引的类型&#xff0c;各类索引有各自的数据结构实现。 1.2 索引的作用 &#x1f693;&#xff08;1&#…

Android修行手册 - 阴影效果的几种实现以及一些特别注意点

点击跳转专栏>Unity3D特效百例点击跳转专栏>案例项目实战源码点击跳转专栏>游戏脚本-辅助自动化点击跳转专栏>Android控件全解手册点击跳转专栏>Scratch编程案例点击跳转>软考全系列点击跳转>蓝桥系列点击跳转>ChatGPT和AIGC &#x1f449;关于作者 专…

m1 rvm install 3.0.0 Error running ‘__rvm_make -j8‘

在使用M1 在安装cocopods 前时&#xff0c;安装 rvm install 3.0.0遇到 rvm install 3.0.0 Error running __rvm_make -j8 备注: 该图片是借用其他博客图片&#xff0c;因为我的环境解决完没有保留之前错误信息。 解决方法如下&#xff1a; 1. brew uninstall --ignore-depe…

TCP协议通讯流程

文章目录&#xff1a; 通讯流程全过程浏览建立连接过程数据传输过程断开连接问题 通讯流程全过程浏览 下图是基于TCP协议的客户端/服务器程序的一般流程&#xff1a; 上图就是TCP协议的通信流程&#xff0c;接下来认识初步认识以下TCP建立连接&#xff08;三次握手&#xff0…

Notion汉化

Notion真无语&#xff0c;汉化版都没有。真的无力吐槽。 2023.11.7汉化经历 教程链接&#xff1a;github Reamd7/notion-zh_CN at 2.4.20-handmade (github.com) 网页版&#xff1a; 油猴下载插件。 Notion中文汉化 浏览器插件下载 windows&#xff1a; github realse 这…

【带头学C++】----- 六、结构体 ---- 6.7 共用体以及枚举类型

6.7 共用体以及枚举类型 结构体:结构体用于组合不同类型的数据&#xff0c;每个字段占用独立的内存空间。 共用体:共用体也组合不同类型的数据&#xff0c;但所有字段共享同一块内存。 因此&#xff0c;结构体适合表示具有多个属性的对象&#xff0c;而共用体适合表示可以具…