MySQL数据碎片的整理和分析

64次阅读

共计 3881 个字符，预计需要花费 10 分钟才能阅读完成。

MySQL 数据碎片的整理和分析，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

MySQL 具有相当多不同种类的存储引擎来实现列表中的数据存储功能。每当 MySQL 从你的列表中删除了一行内容，该段空间就会被留空。而在一段时间内的大量删除操作，会使这种留空的空间变得比存储列表内容所使用的空间更大。当 MySQL 对数据进行扫描时，它扫描的对象实际是列表的容量需求上限，也就是数据被写入的区域中处于峰值位置的部分。如果进行新的插入操作，MySQL 将尝试利用这些留空的区域，但仍然无法将其彻底占用。这种额外的破碎的存储空间在读取效率方面比正常占用的空间要低得多。
以下实验举例说明:

C:\Users\duansf mysql -uroot -p123456
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 4
Server version: 5.5.13 MySQL Community Server (GPL)

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type help; or \h for help. Type \c to clear the current input statement.

mysql

创建一个测试库:

mysql create database frag_test;
Query OK, 1 row affected (0.01 sec)

mysql use frag_test;
Database changed
mysql create table frag_test (c1 varchar(64));
Query OK, 0 rows affected (0.27 sec)

插入几行数据:
mysql insert into frag_test values (this is row 1
Query OK, 1 row affected (0.21 sec)

mysql insert into frag_test values (this is row 2
Query OK, 1 row affected (0.05 sec)

mysql insert into frag_test values (this is row 3
Query OK, 1 row affected (0.03 sec)

现在我们进行碎片查看:
mysql show table status from frag_test\G;
*************************** 1. row ***************************
Name: frag_test
Engine: InnoDB
Version: 10
Row_format: Compact
Rows: 3
Avg_row_length: 5461
Data_length: 16384
Max_data_length: 0
Index_length: 0
Data_free: 10485760
Auto_increment: NULL
Create_time: 2016-03-17 16:36:04
Update_time: NULL
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.00 sec)

ERROR:
No query specified

删除一行，并再次检测:

mysql delete from frag_test where c1 = this is row 2
Query OK, 1 row affected (0.07 sec)

mysql show table status from frag_test\G;
*************************** 1. row ***************************
Name: frag_test
Engine: InnoDB
Version: 10
Row_format: Compact
Rows: 2
Avg_row_length: 8192
Data_length: 16384
Max_data_length: 0
Index_length: 0
Data_free: 10485760
Auto_increment: NULL
Create_time: 2016-03-17 16:36:04
Update_time: NULL
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.00 sec)

Data_free: 10485760 我们看到 Data_free 的值并没有减小

清理碎片试试:

mysql show table status from frag_test\G;
*************************** 1. row ***************************
Name: frag_test
Engine: InnoDB
Version: 10
Row_format: Compact
Rows: 2
Avg_row_length: 8192
Data_length: 16384
Max_data_length: 0
Index_length: 0
Data_free: 9437184
Auto_increment: NULL
Create_time: 2016-03-17 16:36:04
Update_time: NULL
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.00 sec)

Data_free: 9437184 清理碎片后，Data_free 减小了。

“data_free”一栏显示出了我们删除第二行后所产生的留空空间。想象一下如果你有两万行指令的话，结果是什么样的。
以此推算，它们将耗费四十万字节的存储空间。现在如果你将两万条命令行删到只剩一行，列表中有用的内容将只占二十字节，
但 MySQL 在读取中会仍然将其视同于一个容量为四十万字节的列表进行处理，并且除二十字节以外，其它空间都被白白浪费了。

备注：
1.MySQL 官方建议不要经常 (每小时或每天) 进行碎片整理，一般根据实际情况，只需要每周或者每月整理一次即可。
2.OPTIMIZE TABLE 只对 MyISAM，BDB 和 InnoDB 表起作用，尤其是 MyISAM 表的作用最为明显。此外，并不是所有表都需要进行碎片整理，
一般只需要对包含可变长度的文本数据类型的表进行整理即可。
3. 在 OPTIMIZE TABLE 运行过程中，MySQL 会锁定表。
4. 默认情况下，直接对 InnoDB 引擎的数据表使用 OPTIMIZE TABLE，可能会显示「Table does not support optimize, doing recreate + analyze instead」的提示信息。
这个时候，我们可以用 mysqld –skip-new 或者 mysqld –safe-mode 命令来重启 MySQL，以便于让其他引擎支持 OPTIMIZE TABLE。

关于 MySQL 数据碎片的整理和分析问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注丸趣 TV 行业资讯频道了解更多相关知识。

正文完