当mysql表从压缩表变成普通表会发生什么

本文章做了把mysql表从压缩表过渡到普通表的实验过程,看看压缩表变成普通表会发生什么?本文针对mysql5.7和mysql8分别进行了实验。

1、什么是表压缩

在将压缩表引入普通表之前,让我们首先普及表压缩是什么。

[En]

Before introducing compressed tables to ordinary tables, let’s first popularize what table compression is.

表压缩,即表中的数据是以压缩格式存储的,压缩可以显著提高处理速度,压缩磁盘。压缩意味着硬盘和内存之间传输的数据更少,占用的内存和硬盘相对更少,这种压缩给二级索引带来的好处更明显,因为索引数据也是压缩的。

[En]

Table compression, which means that the data in the table is stored in a compressed format, compression can significantly improve processing speed and compress the disk. Compression means that less data is transferred between the hard disk and memory and takes up relatively less memory and the hard disk, and this compression brings more obvious benefits to secondary indexes because the index data is also compressed.

表压缩是有很大好处的,能减少磁盘的I/O,还能提高系统吞吐量,节约空间,压缩率越大,占用的磁盘空间越小,文件传输时间提升,降低数据的存储和网络传输成本。

2、如何表压缩( mysql的版本需要大于5.5 )

#打开配置文件
vim /etc/my.inf

#加入配置项
innodb_file_per_table=1
innodb_file_format=Barracuda
innodb_strict_mode=1 #建议加上
innodb_default_row_format = COMPRESSED #在整个库默认启用行压缩格式时设定,一边不改变此值

#重启数据库
systemctl restart mysqld
mysql> alter table t1 ROW_FORMAT=COMPRESSED;
mysql> alter table t1 ROW_FORMAT=DEFAULT;
  • mysql数据库版本:5.7.31
  • linux版本:centos5.7

1、建表和初始化测试数据


#1、建表
CREATE TABLE test_compress (
    id bigint(20) unsigned NOT NULL,
    identification_id int(10) unsigned DEFAULT NULL,
    timestamp datetime NOT NULL,
    action varchar(50) NOT NULL,
    result varchar(50) NOT NULL,
    PRIMARY KEY (id),
    KEY INDEX_test_compress_result (result),
    KEY INDEX_test_compress_timestamp (timestamp)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

#2、插入测试数据(linux里执行脚本)
for NUM in {1..100000}; do mysql -h localhost PS_57 -e "insert into test_compress (id, identification_id, timestamp, action, result) values ($NUM,$NUM*100,now(),concat('string',$NUM),concat('VeryVeryLargeString',$NUM))"; done

2、验证表的大小

让我们验证表的大小(之前执行innodb_stats_persistent_sample_pages=100000 的 ANALYZE 表,以便统计信息尽可能真实)。

set global innodb_stats_persistent_sample_pages=100000;
analyze table test_compress;

+------------------------+---------+----------+----------+
| Table                  | Op      | Msg_type | Msg_text |
+------------------------+---------+----------+----------+
| PS_57.test_compress    | analyze | status   | OK       |
+------------------------+---------+----------+----------+
Query OK, 0 rows affected (0.00 sec)
select table_schema, table_name, table_rows,  round(data_length / 1024 / 1024)+round(index_length / 1024 / 1024)+round(data_free / 1024 / 1024) TOTAL_MB, create_options from information_schema.tables where table_name='test_compress';

+--------------+---------------+------------+----------+----------------+
| table_schema | table_name    | table_rows | TOTAL_MB | create_options |
+--------------+---------------+------------+----------+----------------+
| PS_57        | test_compress |     100000 |       37 |                |
+--------------+---------------+------------+----------+----------------+

3、对表压缩

接下来,我们将用KEY_BLOCK_SIZE=4压缩表(这个大小是任意选择的,在任何时候都没有指示或决定它是否是最优值,事实上,它不是)。

ALTER TABLE test_compress ROW_FORMAT=COMPRESSED,KEY_BLOCK_SIZE=4,ALGORITHM=INPLACE,LOCK=NONE;

Query OK, 0 rows affected (3.33 sec)

我们再次验证表的大小(以前执行innodb_stats_persistent_sample_pages=100000 的 ANALYZE 表,以便统计信息尽可能真实)。

set global innodb_stats_persistent_sample_pages=100000;

Query OK, 0 rows affected (0.00 sec)
analyze table test_compress;

+------------------------+---------+----------+----------+
| Table                  | Op      | Msg_type | Msg_text |
+------------------------+---------+----------+----------+
| PS_57.test_compress    | analyze | status   | OK       |
+------------------------+---------+----------+----------+
Query OK, 0 rows affected (0.00 sec)
select table_schema, table_name, table_rows,  round(data_length / 1024 / 1024)+round(index_length / 1024 / 1024)+round(data_free / 1024 / 1024) TOTAL_MB, create_options from information_schema.tables where table_name='test_compress';

+--------------+---------------+------------+----------+----------------------------------------+
| table_schema | table_name    | table_rows | TOTAL_MB | create_options                         |
+--------------+---------------+------------+----------+----------------------------------------+
| PS_57        | test_compress |     100000 |       19 | row_format=COMPRESSED KEY_BLOCK_SIZE=4 |
+--------------+---------------+------------+----------+----------------------------------------+

这张桌子已经被压缩了,让我们检查一下它的结构。

[En]

The table has been compressed, let’s check its structure.

show create table test_compress;
*************************** 1. row ***************************
       Table: test_compress
Create Table: CREATE TABLE test_compress (
  id bigint(20) unsigned NOT NULL,
  identification_id int(10) unsigned DEFAULT NULL,
  timestamp datetime NOT NULL,
  action varchar(50) NOT NULL,
  result varchar(50) NOT NULL,
  PRIMARY KEY (id),
  KEY INDEX_test_compress_result (result),
  KEY INDEX_test_compress_timestamp (timestamp)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4

1 row in set (0.00 sec)

4、压缩表解压缩(变成普通表)

ALTER TABLE test_compress ROW_FORMAT=DEFAULT,ALGORITHM=INPLACE,LOCK=NONE;

Query OK, 0 rows affected (6.25 sec)
Records: 0  Duplicates: 0  Warnings: 0

拉链解压成功,让我们来检查一下。

[En]

Unzipped successfully, let’s check it.

select table_schema, table_name, table_rows,  round(data_length / 1024 / 1024)+round(index_length / 1024 / 1024)+round(data_free / 1024 / 1024) TOTAL_MB, create_options from information_schema.tables where table_name='test_compress';

+--------------+---------------+------------+----------+--------------------+
| table_schema | table_name    | table_rows | TOTAL_MB | create_options     |
+--------------+---------------+------------+----------+--------------------+
| PS_57        | test_compress |     100000 |       25 | KEY_BLOCK_SIZE=4   |
+--------------+---------------+------------+----------+--------------------+

更好的检查:

show create table test_compress;

*************************** 1. row ***************************
       Table: test_compress
Create Table: CREATE TABLE test_compress (
  id bigint(20) unsigned NOT NULL,
  identification_id int(10) unsigned DEFAULT NULL,
  timestamp datetime NOT NULL,
  action varchar(50) NOT NULL,
  result varchar(50) NOT NULL,
  PRIMARY KEY (id),
  KEY INDEX_test_compress_result (result),
  KEY INDEX_test_compress_timestamp (timestamp)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 KEY_BLOCK_SIZE=4

出了点问题!KEY_BLOCK_SIZE仍然是4。

第二次尝试:

ALTER TABLE test_compress ROW_FORMAT=DEFAULT,KEY_BLOCK_SIZE=0,ALGORITHM=INPLACE,LOCK=NONE;

Query OK, 0 rows affected (2.05 sec)
Records: 0  Duplicates: 0  Warnings: 0
select table_schema, table_name, table_rows,  round(data_length / 1024 / 1024)+round(index_length / 1024 / 1024)+round(data_free / 1024 / 1024) TOTAL_MB, create_options from information_schema.tables where table_name='test_compress';
+--------------+---------------+------------+----------+--------------------+
| table_schema | table_name    | table_rows | TOTAL_MB | create_options     |
+--------------+---------------+------------+----------+--------------------+
| PS_57        | test_compress |     100000 |       25 |                    |
+--------------+---------------+------------+----------+--------------------+

更好的检查:

show create table test_compress\G
*************************** 1. row ***************************
       Table: test_compress
Create Table: CREATE TABLE test_compress (
  id bigint(20) unsigned NOT NULL,
  identification_id int(10) unsigned DEFAULT NULL,
  timestamp datetime NOT NULL,
  action varchar(50) NOT NULL,
  result varchar(50) NOT NULL,
  PRIMARY KEY (id) KEY_BLOCK_SIZE=4,
  KEY INDEX_test_compress_result (result) KEY_BLOCK_SIZE=4,
  KEY INDEX_test_compress_timestamp (timestamp) KEY_BLOCK_SIZE=4
) ENGINE=InnoDB DEFAULT CHARSET=latin1

出了点问题!主键和二级索引都继续显示 KEY_BLOCK_SIZE=4。

尽管当表从压缩转换为未压缩时,在内部,索引的KEY_BLOCK_SIZE支持表的索引,但 CREATE TABLE 语句则不然。起初,这将是一个美学/外观问题,但是当您进行转储时,这是一个真正的问题,因为CREATE TABLE保留了KEY_BLOCK_SIZE值,这并不好。以下是 mysqldump 的输出:

mysqldump -h localhost PS_57 test_compress --no-data > test_compress.sql
cat test_compress.sql
...

--
-- Table structure for table test_compress
--

DROP TABLE IF EXISTS test_compress;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!50503 SET character_set_client = utf8mb4 */;
CREATE TABLE test_compress (
  id bigint(20) unsigned NOT NULL,
  identification_id int(10) unsigned DEFAULT NULL,
  timestamp datetime NOT NULL,
  action varchar(50) NOT NULL,
  result varchar(50) NOT NULL,
  PRIMARY KEY (id) KEY_BLOCK_SIZE=4,
  KEY INDEX_test_compress_result (result) KEY_BLOCK_SIZE=4,
  KEY INDEX_test_compress_timestamp (timestamp) KEY_BLOCK_SIZE=4
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;
ALTER TABLE test_compress
DROP PRIMARY KEY, add PRIMARY KEY (id),
DROP key INDEX_test_compress_result, add key INDEX_test_compress_result (result),
DROP key INDEX_test_compress_timestamp, add key INDEX_test_compress_timestamp (timestamp),
ROW_FORMAT=DEFAULT,KEY_BLOCK_SIZE=0,ALGORITHM=INPLACE,LOCK=NONE;

现在,它具有正确的定义,没有KEY_BLOCK_SIZE:

show create table test_compress;
*************************** 1. row ***************************
       Table: test_compress
Create Table: CREATE TABLE test_compress (
  id bigint(20) unsigned NOT NULL,
  identification_id int(10) unsigned DEFAULT NULL,
  timestamp datetime NOT NULL,
  action varchar(50) NOT NULL,
  result varchar(50) NOT NULL,
  PRIMARY KEY (id),
  KEY INDEX_test_compress_result (result),
  KEY INDEX_test_compress_timestamp (timestamp)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)
select table_schema, table_name, table_rows,  round(data_length / 1024 / 1024)+round(index_length / 1024 / 1024)+round(data_free / 1024 / 1024) TOTAL_MB, create_options from information_schema.tables where table_name='test_compress';
+--------------+---------------+------------+----------+----------------+
| table_schema | table_name    | table_rows | TOTAL_MB | create_options |
+--------------+---------------+------------+----------+----------------+
| PS_57        | test_compress |     100000 |       25 |                |
+--------------+---------------+------------+----------+----------------+

5、针对第4步出现问题的bug

在MySQL 8中,情况如下:

select table_schema, table_name, table_rows,  round(data_length / 1024 / 1024)+round(index_length / 1024 / 1024)+round(data_free / 1024 / 1024) TOTAL_MB, create_options from information_schema.tables where table_name='test_compress';

+--------------+---------------+------------+----------+----------------+
| TABLE_SCHEMA | TABLE_NAME    | TABLE_ROWS | TOTAL_MB | CREATE_OPTIONS |
+--------------+---------------+------------+----------+----------------+
| PS_8         | test_compress |      31000 |       15 |                |
+--------------+---------------+------------+----------+----------------+

让我们执行 ALTER 来压缩表:

alter table test_compress ROW_FORMAT=COMPRESSED,KEY_BLOCK_SIZE=4,ALGORITHM=INPLACE,LOCK=NONE;

Query OK, 0 rows affected (4.54 sec)
Records: 0  Duplicates: 0  Warnings: 0

让我们再检查一下:

analyze table test_compress;

+-----------------------+---------+----------+----------+
| Table                 | Op      | Msg_type | Msg_text |
+-----------------------+---------+----------+----------+
| PS_8.test_compress    | analyze | status   | OK       |
+-----------------------+---------+----------+----------+
1 row in set (0.07 sec)
select table_schema, table_name, table_rows,  round(data_length / 1024 / 1024)+round(index_length / 1024 / 1024)+round(data_free / 1024 / 1024) TOTAL_MB, create_options from information_schema.tables where table_name='test_compress';

+--------------+---------------+------------+----------+----------------------------------------+
| TABLE_SCHEMA | TABLE_NAME    | TABLE_ROWS | TOTAL_MB | CREATE_OPTIONS                         |
+--------------+---------------+------------+----------+----------------------------------------+
| PS_8         | test_compress |     100000 |       19 | row_format=COMPRESSED KEY_BLOCK_SIZE=4 |
+--------------+---------------+------------+----------+----------------------------------------+
show create table test_compress;
*************************** 1. row ***************************
       Table: test_compress
Create Table: CREATE TABLE test_compress (
  id bigint unsigned NOT NULL,
  identification_id int unsigned DEFAULT NULL,
  timestamp datetime NOT NULL,
 action varchar(50) NOT NULL,
  result varchar(50) NOT NULL,
  PRIMARY KEY (id),
  KEY INDEX_test_compress_result (result),
  KEY INDEX_test_compress_timestamp (timestamp)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4
1 row in set (0.01 sec)

到目前为止,一切都与MySQL 5.7相同:KEY_BLOCK_SIZE保留在整个表的定义中,而不是索引的定义中。

同样的,也能通过下面sql对表进行解压缩:

alter table test_compress ROW_FORMAT=DEFAULT, KEY_BLOCK_SIZE=0,ALGORITHM=INPLACE,LOCK=NONE;

Query OK, 0 rows affected (2.56 sec)
Records: 0  Duplicates: 0  Warnings: 0

查看解压缩情况

show create table test_compress;

*************************** 1. row ***************************
       Table: test_compress
Create Table: CREATE TABLE test_compress (
  id bigint unsigned NOT NULL,
  identification_id int unsigned DEFAULT NULL,
  timestamp datetime NOT NULL,
  action varchar(50) NOT NULL,
  result varchar(50) NOT NULL,
  PRIMARY KEY (id),
  KEY INDEX_test_compress_result (result),
  KEY INDEX_test_compress_timestamp (timestamp)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)
select table_schema, table_name, table_rows,  round(data_length / 1024 / 1024)+round(index_length / 1024 / 1024)+round(data_free / 1024 / 1024) TOTAL_MB, create_options from information_schema.tables where table_name='test_compress';

+--------------+---------------+------------+----------+----------------+
| TABLE_SCHEMA | TABLE_NAME    | TABLE_ROWS | TOTAL_MB | CREATE_OPTIONS |
+--------------+---------------+------------+----------+----------------+
| PS_8         | test_compress |     100000 |       25 |                |
+--------------+---------------+------------+----------+----------------+

在MySQL 5.7中,完全解压缩一张压缩表的唯一方法(至少在表及其索引的定义中)是重新生成主键及其所有索引。否则, 主键和二级索引都继续显示压缩表时候的KEY_BLOCK_SIZE。

然后在MySQL8里,修复了这个问题在MySQL5.7出现的问题。

更多资讯,敬请关注微信公众号[程序员],分享优质文章,编程酷科技,帮你成为程序员!

[En]

For more information, please follow the Wechat official account [programmer], share high-quality articles, programming cool techs, to help you become a programmer!

Original: https://www.cnblogs.com/zhbeier/p/16470091.html
Author: 奇想派
Title: 当mysql表从压缩表变成普通表会发生什么

原创文章受到原创版权保护。转载请注明出处:https://www.johngo689.com/505242/

转载文章受原作者版权保护。转载请注明原作者出处!

(0)

大家都在看

  • 微信小程序二维码

    一、获取小程序码的三个接口 不同的接口对应不同的业务场景,接口B用的较多,接口C官方不推荐使用,也就是说根据需码量来决定选择A接口还是B接口。 (1)、接口 A: 适用于需要的码数…

    数据库 2023年6月6日
    0109
  • 避坑!SimpleDateFormat不光线程不安全,还有这个隐患

    众所周知,SimpleDateFormat是多线程不安全的 下面这段代码通过多线程使用同一个SimpleDateFormat对象的parse方法, 多次执行代码来测试,可以看到会出…

    数据库 2023年6月9日
    089
  • Angel工作室ASP.NET(AngelExam)开源驾校考试系统正式发布

    一、Angel工作室ASP.NET(AngelExam)开源驾校考试系统简介 Angel工作室ASP.NET(AngelExam)驾校考试系统是基于asp.net mvc4.5(C…

    数据库 2023年6月14日
    070
  • Java基础四—泛型、注解、异常、反射

    泛型 泛型的本质是为了参数化类型( 在不创建新的类型的情况下,通过泛型指定的不同类型来控制形参具体限制的类型)。也就是说在泛型使用过程中,操作的数据类型被指定为一个参数,这种参数类…

    数据库 2023年6月6日
    082
  • Shell脚本简单示例

    Shell编程100例:https://zhuanlan.zhihu.com/p/509956726?utm_source=wechat_session&utm_mediu…

    数据库 2023年6月14日
    083
  • MySQL高可用架构搭建实战

    前言 对于 MySQL 数据库作为各个业务系统的存储介质,在系统中承担着非常重要的职责,如果数据库崩了,那么对于读和写数据库的操作都会受到影响。如果不能迅速恢复,对业务的影响是非常…

    数据库 2023年5月24日
    0101
  • WIN10下启动VMware虚拟机蓝屏的解决办法

    问题: 每次启动虚拟机就会蓝屏,提示错误代码: PAGE_FAULT_IN_NONPAGED_AREA 解决办法: 禁用 Hyper-V 功能 打开”控制面板&#821…

    数据库 2023年6月14日
    079
  • Java学习-第一部分-第二阶段-第二节:枚举和注释

    自定义类实现枚举 先看一个需求 要求创建季节(Season)对象,请设计并完成。 创建Season对象有如下特点 1.季节的值是有限的几个值(spring, summer, aut…

    数据库 2023年6月11日
    079
  • 1001-MySQL学习-第一节自习课

    MySQL学习(第一节自习课) 一. 软件下载、安装 下载地址:https://dev.mysql.com/downloads/installer/ 位置:mysql->in…

    数据库 2023年5月24日
    086
  • Spring MVC的生命周期与简单三大组件的简单介绍

    1.说到Spring MVC就会想到它是基于MVC设计模式的思想来设计的: 那么MVC设计模式是什么呢? 下面来介绍一下 MVC 设计模式 MVC是模型(model)-视图(vie…

    数据库 2023年6月6日
    078
  • 18-网络七层架构

    七层架构主要包括 ①、 物理层 主要定义物理设备标准,如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。它的主要作用是传输比特流(就是由 1、0 转化为电流强弱来进行传输…

    数据库 2023年6月16日
    073
  • eclipse反编译插件

    1、在eclipse的help—》Install New Software…中添加新软件开发,添加它的源: undefined name : jd – ec…

    数据库 2023年6月11日
    071
  • SQL基础一

    一、SQL基本术语 数据库管理系统(DBMS,database management system)。人们通常用数据库这个术语来代表他们使用的数据库软件,这是不正确的。确切地说,数…

    数据库 2023年6月16日
    060
  • 删除MySQL数据用户

    mysql删除用户的方法: 1、使用”drop user 用户名;”命令删除; 2、使用”delete from user where user…

    数据库 2023年6月14日
    074
  • MySQL函数学习(三)—–日期和时间函数

    注:笔记旨在记录 三、MySQL 日期和时间函数 3.1 获取时间、日期、年、月、日、周、日相关函数 \ 函 数 名 称 作 用 1 CURDATE 和 CU…

    数据库 2023年6月16日
    064
  • 【StoneDB技术解析】验证相关数据包是否需要解压缩

    在StoneDB中,数据包分为以下几类: 通过对数据包的划分,知识网格技术过滤掉不相关的数据包,读取相关的数据包和可疑的数据包。其中相关的数据包不需要解压缩,只读取元数据,不会发生…

    数据库 2023年5月24日
    069
亲爱的 Coder【最近整理,可免费获取】👉 最新必读书单  | 👏 面试题下载  | 🌎 免费的AI知识星球