如何压缩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。至于哪种压缩算法最优，暂时没办法简单量化，依赖表中的数据分布或者业务请求。

常规办法：

1）删除不必要的数据和无用的ACCESS数据库对象例如表、查询、窗体和模块等；

2）压缩数据库

ACCESS2003压缩举例：打开数据库，点击菜单（工具）——数据库实用工具——压缩和修复数据库

非常规办法：

ACCESS数据库经过一段时间添加、更改和删除数据库对象后会产生很多代码及数据库对象碎片和垃圾，对于这些东西常规办法是无法清除的。这也是为什么你的ACCESS数据删除很多数据后，大小不变的原因所在。

怎么办呢？可以这样做：先建立一个同名空白数据库，放在另一个文件夹下，接着打开该空白数据库，导入原数据库全部有用的对象（包括：表、窗体、查询、模块、页、宏，无用的不要导入）

ACCESS2003导入对象举例：文件——获取外部数据——导入 ，打开“导入”对话框选择需要缩小的数据库后，点击导入按钮，打开“导入对象”对话框 选择全部有用的数据库对象，例如表、窗体等等后点击“确定”按钮 完成导入全部数据库对象。

经过上述过程后，所有的数据库垃圾都会被清除掉。再对其进行一次压缩 *** 作，ACCESS数据库将会处在理论上最小状态。

可以使用DBCC

SHRINKDATABASE

和DBCC

SHRINKFILE

命令来压缩数据库。

其中DBCC

SHRINKDATABASE

命令对数据库进行压缩，DBCC

SHRINKFILE

命令对数据库中指定的文件进行压缩。

DBCC

SHRINKDATABASE

命令语法如下：

DBCC

SHRINKDATABASE

(database_name

[,

target_percent]

[,

{NOTRUNCATE

|

TRUNCATEONLY}]

)

各参数说明如下：

target_percent：

指定将数据库压缩后，未使用的空间占数据库大小的百分之几。如果指定的百分比过大，超过了压缩前未使用空间所占的比例，则数据库不会被压缩。并且压缩后的数据库不能比数据库初始设定的容量小。

NOTRUECATE：

将数据库缩减后剩余的空间保留在数据库，中不返还给 *** 作系统

，如果不选择此选项，则剩余的空间返还给 *** 作系统。

TRUNCATEONLY

：

将数据库缩减后剩余的空间返还给 *** 作系统。使用此命令时SQL

Server

将文件缩减到最后一个文件分配，区域但不移动任何数据文件。选择此项后，target_percent

选项就无效了。

---