mysql从共享表空间修改为单个表的表空间存储方式是什么

49次阅读

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

本篇文章为大家展示了 mysql 从共享表空间修改为单个表的表空间存储方式是什么，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。

使用过 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
total 14G
-rw-r–r– 1 root root 0 Dec 1 14:31 debian-5.1.flag
-rw-rw—- 1 mysql mysql 5.0M Jan 17 21:31 ib_logfile0
-rw-rw—- 1 mysql mysql 5.0M Jan 17 21:29 ib_logfile1
-rw-rw—- 1 mysql mysql 14G Jan 17 21:31 ibdata1
drwx—— 2 mysql root 4.0K Dec 1 14:31 mysql
-rw-rw—- 1 root root 6 Dec 1 14:31 mysql_upgrade_info
drwx—— 2 mysql mysql 4.0K Jan 17 21:29 zabbix
共享表数据空间文件 ibdata1 大小已经达到了 14G

登陆 MySQL 查看哪些表占用了空间
$ mysql -uroot -p
mysql select table_name, (data_length+index_length)/1024/1024 as total_mb, table_rows from information_schema.tables where table_schema= zabbix

+———————–+—————+————+
| table_name | total_mb | table_rows |
+———————–+—————+————+
| acknowledges | 0.06250000 | 0 |
….
| help_items | 0.04687500 | 103 |
| history | 9678.00000000 | 123981681 |
| history_log | 0.04687500 | 0 |
…
| history_text | 0.04687500 | 0 |
| history_uint | 5386.98437500 | 57990562 |
| history_uint_sync | 0.04687500 | 0 |
…
| timeperiods | 0.01562500 | 0 |
| trends | 54.54687500 | 537680 |
| trends_uint | 100.53125000 | 1035592 |
…
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
mysql use zabbix;
Database changed

mysql truncate table history;
Query OK, 123981681 rows affected (0.23 sec)

mysql optimize table history;
1 row in set (0.02 sec)

mysql truncate table history_uint;
Query OK, 57990562 rows affected (0.12 sec)

mysql optimize table history_uint;
1 row in set (0.03 sec)

mysql truncate table trends;
Query OK, 537680 rows affected (0.04 sec)

mysql optimize table trends;
1 row in set (0.02 sec)

mysql truncate table trends_uint;
Query OK, 1035592 rows affected (0.02 sec)

mysql optimize table trends_uint;
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
mysql show variables like %per_table%
+———————–+——-+
| Variable_name | Value |
+———————–+——-+
| innodb_file_per_table | ON |
+———————–+——-+
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?
#!/bin/bash
DATE=`date -d 30 days ago `
CLOCK=`date +%s -d ${DATE} `
MYSQL= mysql -uroot -p zabbix

for TABLE in history trends
do
$MYSQL -e DELETE FROM ${TABLE} WHERE clock ${CLOCK};
$MYSQL -e OPTIMIZE TABLE ${TABLE};
$MYSQL -e DELETE FROM ${TABLE}_uint WHERE clock ${CLOCK};
$MYSQL -e OPTIMIZE TABLE ${TABLE}_uint;
done
12. 最后，恢复相关服务进程
$ sudo /etc/init.d/zabbix-server start
$ sudo /etc/init.d/apache2 start