共享表结构和独立表结构对比（互联网分享）
1、共享表空间（默认）
优点：
可以放表空间分成多个文件存放到各个磁盘上（表空间文件大小不受表大小的限制，如一个表可以分布在不同步的文件上）。数据和文件放在一起方便管理。
缺点：
所有的数据和索引存放到一个文件中以为着将有一个很常大的文件，虽然可以把一个大文件分成多个小文件，但是多个表及索引在表空间中混合存储，这样对于一个表做了大量删除操作后表空间中将会有大量的空隙，特别是对于统计分析，日值系统这类应用最不适合用共享表空间。
我们知道共享表空间管理会出现表空间分配后不能回缩的问题，当出现临时建索引或是创建一个临时表的操作表空间扩大后，就是删除相关的表也没办法回缩 那部分空间了。我们存在磁盘监控时，也许就报警不断了，但实际上MySQL还可以运行良好。另外，当磁盘上占用较多时性能也不是太好。
这种情况处理只能是是建一个新的Slave从主库上Dump出来，然后在Dump到从库中，动作较大。
对于InnoDB Hot Backup备份的操作（或是直接冷备），每次需要CP的文件比较大。如果现在有180G的表空间，但实际数据只有50多G，那么我们将面对每次需要拷180G的数据。
这种方式也许mysqldump是一个好的处理方式了。
2、独立表空间（推荐）
优点：
（1）每个表都有自已独立的表空间。
（2）每个表的数据和索引都会存在自已的表空间中。
（3）可以实现单表在不同的数据库中移动。
（4）空间可以回收（除drop table操作处，表空不能自已回收）
a) Drop table操作自动回收表空间，如果对于统计分析或是日值表，删除大量数据后可以通过:alter table TableName engine=innodb;回缩不用的空间。
b) 对于使innodb-plugin的Innodb使用turncate table也会使空间收缩。
c) 对于使用独立表空间的表，不管怎么删除，表空间的碎片不会太严重的影响性能，而且还有机会处理。
缺点：
单表增加过大，如超过100个G。
结论：
共享表空间在Insert操作上少有优势。其它都没独立表空间表现好。当启用独立表空间时，请合理调整一 下：innodb_open_files 。
实际遇到的问题
最近发现zabbix服务器ibdata1文件很大，高达12GB。
网上查阅了zabbix的数据库存储原理,发现zabbix库是使用的innodb引擎的共享表空间,innodb把数据和索引都放在ibdata1下,随着数据增长,ibdata1会越来越大。性能方面会有影响。
原来默认情况下innodb会将所有的数据库InnoDB引擎的表数据存储在一个共享空间中ibdata1,而且增删数据库的时候，ibdata1文件不会自动收缩，单个数据库的备份也将成为问题。
所以决定将innodb的共享表空间改成独立表空间。
方法一（清空history等大表数据，然后备份数据库、修改参数、还原数据库）
1、查看是否开启了独立表空间，并且查看哪些表占用了空间
MariaDB [(none)]> show variables like '%per_table%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | innodb_file_per_table | OFF | +-----------------------+-------+ 1 row in set (0.00 sec) MariaDB [(none)]> 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 | | actions | 0.04687500 | 14 | | alerts | 5.67187500 | 8314 | | application_discovery | 0.04687500 | 0 | | application_prototype | 0.04687500 | 1 | | application_template | 2.37500000 | 13963 | | applications | 1.96875000 | 14024 | | auditlog | 18.54687500 | 102648 | | auditlog_details | 0.42187500 | 1948 | | autoreg_host | 0.03125000 | 0 | | conditions | 0.03125000 | 61 | | config | 0.04687500 | 1 | | corr_condition | 0.03125000 | 0 | | corr_condition_group | 0.03125000 | 0 | | corr_condition_tag | 0.01562500 | 0 | | corr_condition_tagpair | 0.01562500 | 0 | | corr_condition_tagvalue | 0.01562500 | 0 | | corr_operation | 0.03125000 | 0 | | correlation | 0.04687500 | 0 | | dbversion | 0.01562500 | 1 | | dchecks | 0.03125000 | 1 | | dhosts | 0.03125000 | 0 | | drules | 0.04687500 | 1 | | dservices | 0.04687500 | 0 | | escalations | 0.03125000 | 154 | | event_recovery | 14.10937500 | 15170 | | event_tag | 0.03125000 | 0 | | events | 41.09375000 | 48127 | | expressions | 0.03125000 | 6 | | functions | 10.78125000 | 56183 | | globalmacro | 0.03125000 | 1 | | globalvars | 0.01562500 | 0 | | graph_discovery | 0.03125000 | 88 | | graph_theme | 0.03125000 | 2 | | graphs | 6.09375000 | 17348 | | graphs_items | 12.20312500 | 73151 | | group_discovery | 0.03125000 | 0 | | group_prototype | 0.06250000 | 7 | | groups | 0.03125000 | 19 | | history | 2138.18750000 | 20528213 | | history_log | 1.03125000 | 33 | | history_str | 1.45312500 | 4150 | | history_text | 1.03125000 | 718 | | history_uint | 3719.29687500 | 43986021 | | host_discovery | 0.04687500 | 2 | | host_inventory | 0.01562500 | 0 | | hostmacro | 0.03125000 | 0 | | hosts | 0.48437500 | 707 | | hosts_groups | 0.15625000 | 806 | | hosts_templates | 0.15625000 | 777 | | housekeeper | 0.01562500 | 204 | | httpstep | 0.03125000 | 3 | | httpstepitem | 0.04687500 | 9 | | httptest | 0.07812500 | 3 | | httptestitem | 0.04687500 | 9 | | icon_map | 0.04687500 | 0 | | icon_mapping | 0.04687500 | 0 | | ids | 0.01562500 | 43 | | images | 1.53125000 | 232 | | interface | 0.18750000 | 924 | | interface_discovery | 0.03125000 | 0 | | item_application_prototype | 0.04687500 | 1 | | item_condition | 0.21875000 | 1399 | | item_discovery | 0.75000000 | 5326 | | items | 47.15625000 | 105674 | | items_applications | 17.21875000 | 119577 | | maintenances | 0.04687500 | 0 | | maintenances_groups | 0.04687500 | 0 | | maintenances_hosts | 0.04687500 | 0 | | maintenances_windows | 0.04687500 | 0 | | mappings | 0.03125000 | 143 | | media | 0.04687500 | 15 | | media_type | 0.03125000 | 6 | | opcommand | 0.03125000 | 4 | | opcommand_grp | 0.04687500 | 0 | | opcommand_hst | 0.04687500 | 4 | | opconditions | 0.03125000 | 0 | | operations | 0.03125000 | 29 | | opgroup | 0.04687500 | 1 | | opinventory | 0.01562500 | 0 | | opmessage | 0.03125000 | 23 | | opmessage_grp | 0.04687500 | 5 | | opmessage_usr | 0.04687500 | 15 | | optemplate | 0.04687500 | 1 | | problem | 5.45312500 | 20859 | | problem_tag | 0.04687500 | 0 | | profiles | 0.35937500 | 1626 | | proxy_autoreg_host | 0.03125000 | 0 | | proxy_dhistory | 0.03125000 | 0 | | proxy_history | 0.03125000 | 0 | | regexps | 0.03125000 | 5 | | rights | 0.04687500 | 19 | | screen_user | 0.04687500 | 0 | | screen_usrgrp | 0.04687500 | 0 | | screens | 0.04687500 | 14 | | screens_items | 0.03125000 | 51 | | scripts | 0.06250000 | 3 | | service_alarms | 0.04687500 | 0 | | services | 0.03125000 | 0 | | services_links | 0.04687500 | 0 | | services_times | 0.03125000 | 0 | | sessions | 2.01562500 | 6514 | | slides | 0.04687500 | 1 | | slideshow_user | 0.04687500 | 0 | | slideshow_usrgrp | 0.04687500 | 0 | | slideshows | 0.04687500 | 1 | | sysmap_element_url | 0.03125000 | 0 | | sysmap_url | 0.03125000 | 0 | | sysmap_user | 0.04687500 | 0 | | sysmap_usrgrp | 0.04687500 | 0 | | sysmaps | 0.07812500 | 1 | | sysmaps_elements | 0.09375000 | 1 | | sysmaps_link_triggers | 0.04687500 | 0 | | sysmaps_links | 0.06250000 | 0 | | task | 0.01562500 | 0 | | task_close_problem | 0.01562500 | 0 | | timeperiods | 0.01562500 | 0 | | trends | 73.68750000 | 822417 | | trends_uint | 36.59375000 | 496174 | | trigger_depends | 0.04687500 | 65 | | trigger_discovery | 0.03125000 | 106 | | trigger_tag | 0.03125000 | 0 | | triggers | 18.31250000 | 46005 | | users | 0.03125000 | 10 | | users_groups | 0.04687500 | 11 | | usrgrp | 0.03125000 | 12 | | valuemaps | 0.03125000 | 17 | +----------------------------+---------------+------------+ 127 rows in set (12.41 sec) history（2052万行，2.1GB）、history_unit（4300万行，3.7G） trends（73万行）、trends_uint（36万行）
由于数据量太大，按照普通的方式delete数据的话基本上不太可能。决定直接采用truncate table的方式来快速清空这些表的数据，再使用mysqldump导出数据，删除共享表空间数据文件，重新导入数据。
2、停止相关服务，避免改造时写入数据
[root@localhost ~]# systemctl stop zabbix-server [root@localhost ~]# systemctl stop httpd
3、清空历史数据
mysql > use zabbix;
mysql > truncate table history;
mysql > optimize table history;
mysql > truncate table history_uint;
mysql > optimize table history_uint;
mysql > truncate table trends;
mysql > optimize table trends;
mysql > truncate table trends_uint;
mysql > optimize table trends_uint;
MariaDB [(none)]> use zabbix; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed MariaDB [zabbix]> truncate table history; Query OK, 0 rows affected (0.60 sec) MariaDB [zabbix]> optimize table history; +----------------+----------+----------+-------------------------------------------------------------------+ | Table | Op | Msg_type | Msg_text | +----------------+----------+----------+-------------------------------------------------------------------+ | zabbix.history | optimize | note | Table does not support optimize, doing recreate + analyze instead | | zabbix.history | optimize | status | OK | +----------------+----------+----------+-------------------------------------------------------------------+ 2 rows in set (0.33 sec) MariaDB [zabbix]> truncate table history_uint; Query OK, 0 rows affected (0.15 sec) MariaDB [zabbix]> optimize table history_uint; +---------------------+----------+----------+-------------------------------------------------------------------+ | Table | Op | Msg_type | Msg_text | +---------------------+----------+----------+-------------------------------------------------------------------+ | zabbix.history_uint | optimize | note | Table does not support optimize, doing recreate + analyze instead | | zabbix.history_uint | optimize | status | OK | +---------------------+----------+----------+-------------------------------------------------------------------+ 2 rows in set (0.15 sec) MariaDB [zabbix]> truncate table trends; Query OK, 0 rows affected (0.02 sec) MariaDB [zabbix]> optimize table trends; +---------------+----------+----------+-------------------------------------------------------------------+ | Table | Op | Msg_type | Msg_text | +---------------+----------+----------+-------------------------------------------------------------------+ | zabbix.trends | optimize | note | Table does not support optimize, doing recreate + analyze instead | | zabbix.trends | optimize | status | OK | +---------------+----------+----------+-------------------------------------------------------------------+ 2 rows in set (0.01 sec) MariaDB [zabbix]> truncate table trends_uint; Query OK, 0 rows affected (0.01 sec) MariaDB [zabbix]> optimize table trends_uint; +--------------------+----------+----------+-------------------------------------------------------------------+ | Table | Op | Msg_type | Msg_text | +--------------------+----------+----------+-------------------------------------------------------------------+ | zabbix.trends_uint | optimize | note | Table does not support optimize, doing recreate + analyze instead | | zabbix.trends_uint | optimize | status | OK | +--------------------+----------+----------+-------------------------------------------------------------------+ 2 rows in set (0.02 sec)
4、备份数据
[root@localhost ~]# mysqldump -u root -p --databases zabbix |gzip>201803211714.sql.gz
5、停止数据库
[root@localhost mysql]# systemctl stop mariadb.service
6、删除共享表空间数据文件
[root@localhost ~]# cd /var/lib/mysql/ [root@localhost mysql]# rm -rf ibdata1 ib_logfile0 ib_logfile1
7、增加innodb_file_per_table独立表空间参数
[root@localhost mysql]# vi /etc/my.cnf # vi /etc/my.cnf 在[mysqld]下添加一行 innodb_file_per_table=1
8、启动MySQL
[root@localhost mysql]# systemctl start mariadb.service
9、查看参数是否生效
MariaDB [(none)]> show variables like '%per_table%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | innodb_file_per_table | ON | +-----------------------+-------+ 1 row in set (0.00 sec)
10、重新导入数据和确认
[root@localhost ~]# gunzip 201803211714.sql.gz [root@localhost ~]# mysql -uroot -p zabbix <201803211714.sql
数据库目录innodb表应该有.ibd各自的文件
备注：另外推荐使用独立表空间的原因
从性能上对比共享表空间和独立表空间：
共享表空间在Insert操作有优势。其它都没独立表空间表现好。这里也有一个TIPS当启用独立表空间时，请合理调整一下：innodb_open_files 。
从Linux系统处理上出发：
所以对于大量更新操作的系统不太适合用共享表空间
方法二（先备份数据库、修改参数、删除ibdata1等文件、还原数据库）---没试过，因为我不想要历史数据。
1.查看是否开启
mysql> show variables like '%per_table%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | innodb_file_per_table | OFF | +-----------------------+---
2、编辑my.cnf配置文件[mysqld]加入下面这些行
innodb_file_per_table = 1
3、备份数据库
[root@localhost ~]# mysqldump -u root -p --databases zabbix |gzip>201803211702.sql.gz
4、停止数据库
[root@localhost ~]# mysqladmin --host=localhost --user=root --password shutdown
5、删除相关文件
ibdata1
ib_logfile*
6、启动mysql服务
[root@localhost ~]# systemctl start mariadb.service
7、还原数据
[root@localhost ~]# systemctl stop zabbix-server [root@localhost ~]# gunzip 201803211702.sql.gz [root@localhost ~]# mysql -uroot -p zabbix <20180309.sql
8、验证独享空间是否开启
mysql> show variables like '%per_table%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | innodb_file_per_table | ON | +-----------------------+---
原文地址：http://blog.51cto.com/net881004/2089561
