mysql從共享表空間修改為單個表的表空間存儲方式是什么

136次閱讀

共計 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