本文目录一览：
如何压缩Mysql数据库
压缩表从名字上来看，简单理解为压缩后的表，也就是把原始表根据一定的压缩算法按照一定的压缩比率压缩后生成的表。
1.1 压缩能力强的产品
表压缩后从磁盘占用上看要比原始表要小很多。如果你熟悉列式数据库，那对这个概念一定不陌生。比如，基于 PostgreSQL 的列式数据库 Greenplum；早期基于 MySQL 的列式数据库 inforbright；或者 Percona 的产品 tokudb 等，都是有压缩能力非常强的数据库产品。
1.2 为什么要用压缩表？
情景一：磁盘大小为 1T，不算其他的空间占用，只能存放 10 张 100G 大小的表。如果这些表以一定的比率压缩后，比如每张表从 100G 压缩到 10G，那同样的磁盘可以存放 100 张表，表的容量是原来的 10 倍。情景二：默认 MySQL 页大小 16K，而 OS 文件系统一般块大小为 4K，所以在 MySQL 在刷脏页的过程中，有一定的概率出现页没写全而导致数据坏掉的情形。比如 16K 的页写了 12K，剩下 4K 没写成功，导致 MySQL 页数据损坏。这个时候就算通过 Redo Log 也恢复不了，因为几乎有所有的关系数据库采用的 Redo Log 都记录了数据页的偏移量，此时就算通过 Redo Log 恢复后，数据也是错误的。所以 MySQL 在刷脏数据之前，会把这部分数据先写入共享表空间里的 DOUBLE WRITE BUFFER 区域来避免这种异常。此时如果 MySQL 采用压缩表，并且每张表页大小和磁盘块大小一致，比如也是 4K，那 DOUBLE WRITE BUFFER 就可以不需要，这部分开销就可以规避掉了。查看文件系统的块大小：
root@ytt-pc:/home/ytt# tune2fs -l /dev/mapper/ytt–pc–vg-root | grep -i ‘block size’Block size: 4096
1.3 压缩表的优势
压缩表的优点非常明显，占用磁盘空间小！由于占用空间小，从磁盘置换到内存以及之后经过网络传输都非常节省资源。
简单来讲：节省磁盘 IO，减少网络 IO。
1.4 压缩表的缺陷
当然压缩表也有缺点，压缩表的写入（INSERT,UPDATE,DELETE）比普通表要消耗更多的 CPU 资源。
压缩表的写入涉及到解压数据，更新数据，再压缩数据，比普通表多了解压和再压缩两个步骤，压缩和解压缩需要消耗一定的 CPU 资源。所以需要选择一个比较优化的压缩算法。
1.5 MySQL 支持的压缩算法
这块是 MySQL 所有涉及到压缩的基础，不仅仅用于压缩表，也用于其它地方。比如客户端请求到 MySQL 服务端的数据压缩；主从之间的压缩传输；利用克隆插件来复制数据库操作的压缩传输等等。
从下面结果可以看到 MySQL 支持的压缩算法为 zlib 和 zstd，MySQL 默认压缩算法为 zlib，当然你也可以选择非 zlib 算法，比如 zstd。至于哪种压缩算法最优，暂时没办法简单量化，依赖表中的数据分布或者业务请求。
怎么修改mysql数据库临时表空间大小
以MySQL 8.0 来说，通过查看 8.0 的官方文档得知，8.0 的临时表空间分为会话临时表空间和全局临时表空间，会话临时表空间存储用户创建的临时表和当 InnoDB 配置为磁盘内部临时表的存储引擎时由优化器创建的内部临时表，当会话断开连接时，其临时表空间将被截断并释放回池中；也就是说，在 8.0 中有一个专门的会话临时表空间，当会话被杀掉后，可以回收磁盘空间；而原来的 ibtmp1 是现在的全局临时表空间，存放的是对用户创建的临时表进行更改的回滚段，在 5.7 中 ibtmp1 存放的是用户创建的临时表和磁盘内部临时表；
也就是在 8.0 和 5.7 中 ibtmp1 的用途发生了变化，5.7 版本临时表的数据存放在 ibtmp1 中，在 8.0 版本中临时表的数据存放在会话临时表空间，如果临时表发生更改，更改的 undo 数据存放在 ibtmp1 中；
实验验证：将之前的查询结果保存成临时表，对应会话是 45 号，通过查看对应字典表，可知 45 号会话使用了 temp_8.ibt 这个表空间，通过把查询保存成临时表，可以用到会话临时表空间，如下图：
下一步杀掉 45 号会话，发现 temp_8.ibt 空间释放了，变为了初始大小，状态为非活动的，证明在 mysql8.0 中可以通过杀掉会话来释放临时表空间。
总结：在 mysql5.7 时，杀掉会话，临时表会释放，但是仅仅是在 ibtmp 文件里标记一下，空间是不会释放回操作系统的。如果要释放空间，需要重启数据库；在 mysql8.0 中可以通过杀掉会话来释放临时表空间。
MySQL可以通过配置限制表空间的大小吗?
innodb的可以用以下方式设置
[mysqld]
innodb_data_file_path = ts #用来容纳InnoDB数据表的表空间：可能涉及一个以上的文件；每一个表空间文件的最大长度都必须以B,MB,GB为单位给出；表空间文件的名字必须以分号隔开；最后一个表空间文件还以带有一个autoextend属性和一个最大长度(max:n)。如：ibdata1:1G;ibdata2:1G:autoextend:max:2G。默认设置是ibdata1:10M:autoextend
innodb_autoextend_increment = n #带有autoextend属性的表空间文件每次加大多少兆字节(默认是8MB)，该属性不涉及具体的数据表文件，那些文件的增大速度相对是比较小的
示例：
innodb_data_file_path=ibdata1:50M;ibdata2:50M:autoextend
myisam:
与系统有关
linux怎么修改mysql数据库临时表空间大小
先来说说临时表的概念。 临时表顾名思义，就是临时的，用完销毁掉的表。 数据既可以保存在临时的文件系统上，也可以保存在固定的磁盘文件系统上。 临时表有下面几种：
1全局临时表
这种临时表从数据库实例启动后开始生效，在数据库实例销毁后失效。在MySQL里面这种临时表对应的是内存表，即memory引擎。
2会话级别临时表
这种临时表在用户登录系统成功后生效，在用户退出时失效。在MySQL里的临时表指的就是以 create temporary table 这样的关键词创建的表。
3事务级别临时表
这种临时表在事务开始时生效，事务提交或者回滚后失效。 在MySQL里面没有这种临时表，必须利用会话级别的临时表间接实现。
4检索级别临时表
这种临时表在SQL语句执行之间产生，执行完毕后失效。 在MySQL里面这种临时表不是很固定，跟随MySQL默认存储引擎来变化。比如默认存储引擎是MyISAM,临时表的引擎就是MyISAM,并且文件生成形式以及数据运作形式和MyISAM一样，只是数据保存在内存里；如果默认引擎是INNODB，那么临时表的引擎就是INNODB，此时它的所有信息都保存在共享表空间ibdata里面。
MySQL 5.7对于InnoDB存储引擎的临时表空间做了优化。在MySQL 5.7之前，INNODB引擎的临时表都保存在ibdata里面，而ibdata的贪婪式磁盘占用导致临时表的创建与删除对其他正常表产生非常大的性能影响。在MySQL5.7中，对于临时表做了下面两个重要方面的优化：
MySQL5.7 把临时表的数据以及回滚信息（仅限于未压缩表）从共享表空间里面剥离出来，形成自己单独的表空间，参数为innodb_temp_data_file_path。
在MySQL5.7 中把临时表的相关检索信息保存在系统信息表中：information_schema.innodb_temp_table_info. 而MySQL 5.7之前的版本想要查看临时表的系统信息是没有太好的办法。
需要注意的一点就是，虽然INNODB临时表有自己的表空间，但是目前还不能自己定义临时表空间文件的保存路径，只能是继承innodb_data_home_dir。此时如果想要拿其他的磁盘，比如内存盘来充当临时表空间的保存地址，只能用老办法，做软链。举个小例子：
我现在用的OS是 Ubuntu12.X，想用tmpfs文件系统充当临时表空间，
root@ytt-master-VirtualBox:/usr/local/mysql/data# ln -s/run/shm/ /usr/local/mysql/data/tmp_space2
root@ytt-master-VirtualBox:/usr/local/mysql/data#ls -l | grep ‘shm’
lrwxrwxrwx1 root root 9 Nov 13 10:28tmp_space2 – /run/shm/
然后把
innodb_temp_data_file_path=tmp_space2/ibtmp2:200M:autoextend
添加到my.cnf里的[mysqld]下面一行
重启MySQL服务后，
mysqlselect @@innodb_temp_data_file_path\G
***************************1. row ***************************
@@innodb_temp_data_file_path:tmp_space2/ibtmp2:200M:autoextend
1 rowin set (0.00 sec)
先写一个批量创建临时表的存储过程：
DELIMITER$$
USE`t_girl`$$
DROPPROCEDURE IF EXISTS `sp_create_temporary_table`$$
CREATEDEFINER=`root`@`localhost` PROCEDURE `sp_create_temporary_table`(
IN f_cnt INT UNSIGNED )
BEGIN
DECLARE i INT UNSIGNED DEFAULT 1;
WHILE i = f_cnt
DO
SET @stmt = CONCAT(‘create temporarytable tmp’,i,’ ( id int, tmp_desc varchar(60));’);
PREPARE s1 FROM @stmt;
EXECUTE s1;
SET i = i + 1;
END WHILE;
DROP PREPARE s1;
END$$
DELIMITER;
现在来创建10张临时表：
mysqlcall sp_create_temporary_table(10);
QueryOK, 0 rows affected (0.07 sec)
如果在以前，我们只知道创建了10张临时表，但是只能凭记忆或者手工记录下来临时表的名字等信息。
现在可以直接从数据字典里面检索相关数据。
mysql select * frominformation_schema.innodb_temp_table_info;
+———-+————–+——–+——-+———————-+—————+
|TABLE_ID | NAME | N_COLS | SPACE| PER_TABLE_TABLESPACE | IS_COMPRESSED |
+———-+————–+——–+——-+———————-+—————+
| 56 | #sql1705_2_9 | 5 | 36 | FALSE | FALSE |
| 55 | #sql1705_2_8 | 5 | 36 | FALSE |FALSE |
| 54 | #sql1705_2_7 | 5 | 36 | FALSE | FALSE |
| 53 | #sql1705_2_6 | 5 | 36 | FALSE | FALSE |
| 52 | #sql1705_2_5 | 5 | 36 | FALSE |FALSE |
| 51 | #sql1705_2_4 | 5 | 36 | FALSE | FALSE |
| 50 | #sql1705_2_3 | 5 | 36 | FALSE | FALSE |
| 49 | #sql1705_2_2 | 5 | 36 | FALSE |FALSE |
| 48 | #sql1705_2_1 | 5 | 36 | FALSE | FALSE |
| 47 | #sql1705_2_0 | 5 | 36 | FALSE | FALSE |
+———-+————–+——–+——-+———————-+—————+
10rows in set (0.00 sec)
功能性我就写到这里，大家性能方面如果有兴趣可以找时间去测试。
原创文章，作者：小蓝，如若转载，请注明出处：https://www.506064.com/n/288508.html
微信扫一扫 
支付宝扫一扫 