使用参数innodb_file_per_table支持MySQL InnoDB表数据共享空间自动收缩

http://heylinux.com/archives/2367.html

http://blog.csdn.net/ywh147/article/details/8996022

使用过MySQL的同学，刚开始接触最多的莫过于MyISAM表引擎了，这种引擎的数据库会分别创建三个文件：表结构、表索引、表数据空间。我们可以将某个数据库目录直接迁移到其他数据库也可以正常工作。
然而当你使用InnoDB的时候，一切都变了。InnoDB 默认会将所有的数据库InnoDB引擎的表数据存储在一个共享空间中：ibdata1，这样就感觉不爽，增删数据库的时候，ibdata1文件不会自动收缩，单个数据库的备份也将成为问题。通常只能将数据使用mysqldump 导出，然后再导入解决这个问题。
在mysql的配置文件[mysqld]部分，增加innodb_file_per_table参数，可以修改InnoDB为独立表空间模式，每个数据库的每个表都会生成一个数据空间。

独立表空间
优点：
1.每个表都有自已独立的表空间。
2.每个表的数据和索引都会存在自已的表空间中。
3.可以实现单表在不同的数据库中移动。
4.空间可以回收（drop/truncate table方式操作表空间不能自动回收）
5.对于使用独立表空间的表，不管怎么删除，表空间的碎片不会太严重的影响性能，而且还有机会处理。

缺点：
单表增加比共享空间方式更大。

结论：
共享表空间在Insert操作上有一些优势，但在其它都没独立表空间表现好。
当启用独立表空间时，请合理调整一下 innodb_open_files 参数。

下面，就是一次针对线上Zabbix的MySQL数据库history历史记录过多导致ibdata1文件过大的实战解决步骤
1.查看文件大小
$ sudo cd /var/lib/mysql
$ ls -lh

1 total 14G
2 -rw-r--r-- 1 root root 0 Dec 1 14:31 debian-5.1.flag
3 -rw-rw---- 1 mysql mysql 5.0M Jan 17 21:31 ib_logfile0
4 -rw-rw---- 1 mysql mysql 5.0M Jan 17 21:29 ib_logfile1
5 -rw-rw---- 1 mysql mysql 14G Jan 17 21:31 ibdata1
6 drwx------ 2 mysql root 4.0K Dec 1 14:31 mysql
7 -rw-rw---- 1 root root 6 Dec 1 14:31 mysql_upgrade_info
8 drwx------ 2 mysql mysql 4.0K Jan 17 21:29 zabbix

共享表数据空间文件ibdata1大小已经达到了14G

登陆MySQL查看哪些表占用了空间
$ mysql -uroot -p

01 mysql > select table_name, (data_length+index_length)/1024/1024 as total_mb, table_rows from information_schema.tables where table_schema=‘zabbix‘;
02  
03 +-----------------------+---------------+------------+
04 | table_name            | total_mb      | table_rows |
05 +-----------------------+---------------+------------+
06 | acknowledges          |    0.06250000 |          0 |
07 ....
08 | help_items            |    0.04687500 |        103 |
09 | history               | 9678.00000000 |  123981681 |
10 | history_log           |    0.04687500 |          0 |
11 ...
12 | history_text          |    0.04687500 |          0 |
13 | history_uint          | 5386.98437500 |   57990562 |
14 | history_uint_sync     |    0.04687500 |          0 |
15 ...
16 | timeperiods           |    0.01562500 |          0 |
17 | trends                |   54.54687500 |     537680 |
18 | trends_uint           |  100.53125000 |    1035592 |
19 ...
20 103 rows in set (1.46 sec)

可以看到，history表的记录已经达到了9G，123981681条，即1亿2千万条，同时history_unit也比较大，达到了5G，约6千万条；
另外就是trends,trends_uint中也存在一些数据。
由于数据量太大，按照普通的方式delete数据的话基本上不太可能。
因为我们每天会自动发送数据报表，所以决定直接采用truncate table的方式来快速清空这些表的数据，再使用mysqldump导出数据，删除共享表空间数据文件，重新导入数据。

2.停止相关服务，避免写入数据
$ sudo /etc/init.d/zabbix-server stop
$ sudo /etc/init.d/apache2 stop

3.清空历史数据
$ mysql -uroot -p

01 mysql > use zabbix;
02 Database changed
03  
04 mysql > truncate table history;
05 Query OK, 123981681 rows affected (0.23 sec)
06  
07 mysql > optimize table history;
08 1 row in set (0.02 sec)
09  
10 mysql > truncate table history_uint;
11 Query OK, 57990562 rows affected (0.12 sec)
12  
13 mysql > optimize table history_uint;
14 1 row in set (0.03 sec)
15  
16 mysql > truncate table trends;
17 Query OK, 537680 rows affected (0.04 sec)
18  
19 mysql > optimize table trends;
20 1 row in set (0.02 sec)
21  
22 mysql > truncate table trends_uint;
23 Query OK, 1035592 rows affected (0.02 sec)  
24  
25 mysql > optimize table trends_uint;
26 1 row in set (0.01 sec)

4.备份数据
$ mysqldump -uroot -p zabbix > ~/zabbix.sql

5.停止数据库
$ sudo stop mysql

6.删除共享表空间数据文件
$ cd /var/lib/mysql
$ rm ib*

7.增加innodb_file_per_table参数
$ sudo vim /etc/mysql/my.cnf
在[mysqld]下设置

1 innodb_file_per_table=1

8.启动MySQL
$ sudo start mysql

9.查看参数是否生效
$ mysql -uroot -p

1 mysql> show variables like ‘%per_table%‘;
2 +-----------------------+-------+
3 | Variable_name | Value |
4 +-----------------------+-------+
5 | innodb_file_per_table | ON |
6 +-----------------------+-------+
7 1 row in set (0.00 sec)

10.重新导入数据
$ mysql -uroot -p zabbix < ~/zabbix.sql

11.编写每天自动清理数据的脚本，保留30天的数据
$ sudo vim /etc/cron.daily/clean_zabbix_olddata.sh

view source

print?

01 #!/bin/bash
02 DATE=`date -d "30 days ago"`
03 CLOCK=`date +%s -d "${DATE}"`
04 MYSQL="mysql -uroot -p zabbix"
05  
06 for TABLE in history trends
07 do
08   $MYSQL -e "DELETE FROM ${TABLE} WHERE clock < ${CLOCK};"
09   $MYSQL -e "OPTIMIZE TABLE ${TABLE};"
10   $MYSQL -e "DELETE FROM ${TABLE}_uint WHERE clock < ${CLOCK};"
11   $MYSQL -e "OPTIMIZE TABLE ${TABLE}_uint;"
12 done

12.最后，恢复相关服务进程
$ sudo /etc/init.d/zabbix-server start
$ sudo /etc/init.d/apache2 start

时间： 2024-10-29 19:09:41

使用参数innodb_file_per_table支持MySQL InnoDB表数据共享空间自动收缩的相关文章

mysql innodb表分区

分区的一些优点包括:      1).与单个磁盘或文件系统分区相比,可以存储更多的数据.      2).对于那些已经失去保存意义的数据,通常可以通过删除与那些数据有关的分区,很容易地删除那些数据.相反地,在某些情况下,添加新数据的过程又可以通过为那些新数据专门增加一个新的分区,来很方便地实现.通常和分区有关的其他优点包括下面列出的这些.MySQL分区中的这些功能目前还没有实现,但是在我们的优先级列表中,具有高的优先级:我们希望在5.1的生产版本中,能包括这些功能.      3).一些查询可以

MySQL InnoDB表--BTree基本数据结构

MySQL InnoDB表是索引组织表这一点应该是每一个学习MySQL的人都会首先学到的知识,这代表这表中的数据是按照主键顺序存储,也就是说BTree的叶子节点存储了所有该行的数据. 我最开始是搞Oracle的,头一次接触MySQL的时候,默认引擎还是MyISAM.当时我看到公司建立的所有的InnoDB表都会在第一列加一个业务无关的自增主键,我觉得很没有必要,问了些人这么做的意义,得到的答案也是让人搞不懂,其实也都没有说到根本上,只是说这样据说效率会更好.于是我在数据仓库项目的建设时普遍没有采用

关于MySQL InnoDB表的二级索引是否加入主键列的问题解释

关于MySQL InnoDB表的二级索引是否加入主键,总结如下: 1对于MySQL InnoDB表的二级索引是否加入主键,官方也有明确的说明,建议线上MySQL的二级索引创建时强制加入主键所有的列,可以做到所有的MySQL 版本统一. 2.MySQL 5.6.9之前,InnoDB引擎层是会对二级索引做自动扩展,但是优化器不能识别出扩展的主键. 3.MySQL 5.6.9开始InnoDB引擎层是会对二级索引做自动扩展,优化器能识别出扩展的主键. 4.索引的大小一样,二级索引有没有加入主键列,在In

Mysql Innodb 表碎片整理

一.为什么会产生碎片 简单的说,删除数据必然会在数据文件中造成不连续的空白空间,而当插入数据时,这些空白空间则会被利用起来.于是造成了数据的存储位置不连续,以及物理存储顺序与理论上的排序顺序不同,这种是数据碎片.实际上数据碎片分为两种,一种是单行数据碎片,另一种是多行数据碎片.前者的意思就是一行数据,被分成N个片段,存储在N个位置.后者的就是多行数据并未按照逻辑上的顺序排列.当有大量的删除和插入操作时,必然会产生很多未使用的空白空间,这些空间就是多出来的额外空间.索引也是文件数据,所以也会产生索

Innodb表独立空间

需求:MYSQL innodb 每张表一个数据文件 默认情况下,innodb引擎的所有表都存储在一个叫ibdata1的文件中,当数据量很大的时候,这个文件超级大,而且由于磁盘碎片造成很大的性能影响.但是我们可以让每张表一个ibdata文件,具体做法是在mysql配置文件中加入: innodb_file_per_table=1 这样就修改了InnoDB为独立表空间模式,每个数据库的每个表都会生成一个数据空间.重启mysql服务即生效. 查看是否开启: mysql> show variables l

MySQL Innodb表导致死锁日志情况分析与归纳

发现当备份表格的sql语句与删除该表部分数据的sql语句同时运行时,mysql会检测出死锁,并打印出日志 案例描述在定时脚本运行过程中,发现当备份表格的sql语句与删除该表部分数据的sql语句同时运行时,mysql会检测出死锁,并打印出日志.两个sql语句如下:(1)insert into backup_table select * from source_table(2)DELETE FROM source_table WHERE Id>5 AND titleWeight<32768 AND

mysql innodb表 utf8 gbk占用空间相同，毁三观

昨天因为发生字符集转换相关错误,今天想验证下utf8和gbk中英文下各自空间的差距.这一测试,绝对毁三观,无论中文还是中文+英文,gbk和utf8占用的实际物理大小完全相同,根本不是理论上所述的“UTF-8对中文采用3个字节,对英文采用1个字节,GBK对中英文都采用2个字节”,如下所示: 空表: GBK如下: CREATE TABLE `test_char_gbk` ( `gbk_str` varchar(100) DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHA

【转】利用optimize、存储过程和系统表对mysql数据库表进行批量碎片清理释放表空间

本文收集于本人的笔记本,由于找不到原文出处.在此省略,如哪位知道可以联系我加上. 核心是利用mysql系统表和“optimize table 表名”命令,对mysql数据表进行空间的释放.由于delete和drop table都不会释放表空间(truncate 命令会释放表空间[将所有的数据都删除]),所以需要利用optimize 命令进行释放. 这个存储过程目的是给一个库的所有表来整理碎片的.一个表随着插入很频繁,或者一直更新不停的,就会积累好多碎片.如果及时整理一下,查询效率会高出好多. D

MySQL InnoDB存储引擎之表(一)

主要介绍InnoDB存储引擎表的逻辑存储以及实现.重点介绍数据在表中是如何组织和存放的. 1.索引组织表(index organized table) 在InnoDB存储引擎中,表都是根据主键顺序组织存放的,这种存储方式的表叫索引组织表.在InnoDB存在引擎表中,每张表都有个主键(Primary key),如果在创建表时没有显示定义主键,则会按照如下方式选择或者创建主键:a.判定是否有非空的唯一索引(unique not null),如果有则该列即为主键.若果有多个,则选择建表是第一个定义的非