Innodb共享表空间VS独立表空间
时间:2015-01-08 00:30 来源:linux.it.net.cn 作者:IT
在使用Innodb引擎时将要面对两种表空间的管理选择的问题,Innodb有两种管理表空间的方法:
1. 共享表空间(也可以拆分成多个小的表空间)
2. 独立表空间每一个表有一个独立的表空间。
我个人推荐使用独立表空间。在性能和运维上独立表空间比共享的表空间有很多优势。下面我将分别说明一下两种表空间管理的特点。
共享表空间:
优点:
可以放表空间分成多个文件存放到各个磁盘上(表空间文件大小不受表大小的限制,如一个表可以分布在不同步的文件上)。数据和文件放在一起方便管理。
缺点:
所有的数据和索引存放到一个文件中以为着将有一个很常大的文件,虽然可以把一个大文件分成多个小文件,但是多个表及索引在表空间中混合存储,这样对于一个表做了大量删除操作后表空间中将会有大量的空隙,特别是对于统计分析,日值系统这类应用最不适合用共享表空间。
我们知道共享表空间管理会出现表空间分配后不能回缩的问题,当出现临时建索引或是创建一个临时表的操作表空间扩大后,就是删除相关的表也没办法回缩那部分空间了。我们存在磁盘监控时,也许就报警不断了,但实际上MySQL还可以运行良好。另外,当磁盘上占用较多时性能也不是太好。
这种情况处理只能是是建一个新的Slave从主库上Dump出来,然后在Dump到从库中,动作较大。
对于InnoDB Hot Backup备份的操作(或是直接冷备),每次需要CP的文件比较大。如果现在有180G的表空间,但实际数据只有50多G,那么我们将面对每次需要拷180G的数据。
这种方式也许mysqldump是一个好的处理方式了。
独立表空间:
在配置文件(my.cnf)中设置: innodb_file_per_table
优点:
1. 每个表都有自已独立的表空间。
2. 每个表的数据和索引都会存在自已的表空间中。
3. 可以实现单表在不同的数据库中移动。
4. 空间可以回收(除drop table操作处,表空不能自已回收)
a) Drop table操作自动回收表空间,如果对于统计分析或是日值表,删除大量数据后可以通过:alter table TableName engine=innodb;回缩不用的空间。
b) 对于使innodb-plugin的Innodb使用turncate table也会使空间收缩。
c) 对于使用独立表空间的表,不管怎么删除,表空间的碎片不会太严重的影响性能,而且还有机会处理。
缺点:
单表增加过大,如超过100个G。
对于单表增长过大的问题,如果使用共享表空间可以把文件分开,但有同样有一个问题,如果访问的范围过大同样会访问多个文件,一样会比较慢。对于独立表空间也有一个解决办法是:使用分区表,也可以把那个大的表空间移动到别的空间上然后做一个连接。其实从性能上出发,当一个表超过100个G有可能响应也是较慢了,对于独立表空间还容易发现问题早做处理。
备份:
InnoDB Hot Backup(冷备)的表空间cp不会面对很多无用的copy了。而且利用innodb hot backup及表空间的管理命令可以实现单现移动。
监控:
可以更好从系统上监控数据的大小,每个表的大小。
另外推荐使用独立表空间的原因:
从性能上对比共享表空间和独立表空间:
共享表空间在Insert操作上少有优势。其它都没独立表空间表现好。这里也有一个TIPS当启用独立表空间时,请合理调整一下:innodb_open_files 。
从Linux系统处理上出发:
文件系统fsync一大片更新数据,对系统io冲击较大。若分隔成多个小数据fsync,能够减少对读的影响。 同时从mysql代码,发现mysql保证两次fsync之间至少有20ms的sleep,这样的话,若将一次fsync变成多次小数据操作,应该能够减少慢查询的比例。所以对于大量更新操作的系统不太适合用共享表空间。
==========================================================================================
修改为独立表空间:
1.查看当前表空间情况:
mysql> show variables like '%per_table';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| innodb_file_per_table | OFF |
+-----------------------+-------+
1 row in set (0.00 sec)
表示当前是共享表空间。
也可以通过观察含有innodb类型的表的文件来了解:
[root@localhost Idx]# pwd
/home/mysql/data/Idx
[root@localhost Idx]# ls
album.frm artist.frm db.opt Track.frm Track.MYD Track.MYI
想要将共享表空间转化为独立表空间有两种方法:
1.先逻辑备份,然后修改配置文件my.cnf中的参数innodb_file_per_table参数为1,重启服务后将逻辑备份导入即可。
2.修改配置文件my.cnf中的参数innodb_file_per_table参数为1,重启服务后将需要修改的所有innodb表都执行一遍:alter table table_name engine=innodb;
使用第二种方式修改后,原来库中的表中的数据会继续存放于ibdata1中,新建的表才会使用独立表空间
mysql> show variables like '%per_table';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| innodb_file_per_table | ON |
+-----------------------+-------+
1 row in set (0.00 sec)
查看指定库中存储引擎为INNODB的表:
mysql> SELECT
-> `TABLES`.TABLE_SCHEMA,`TABLES`.TABLE_NAME,`TABLES`.`ENGINE`
-> FROM information_schema.`TABLES`
-> WHERE `ENGINE`='INNODB' AND TABLE_SCHEMA='Idx';
+--------------+------------+--------+
| TABLE_SCHEMA | TABLE_NAME | ENGINE |
+--------------+------------+--------+
| Idx | album | InnoDB |
| Idx | artist | InnoDB |
+--------------+------------+--------+
2 rows in set (0.00 sec)
mysql> alter table album engine=innodb;
Query OK, 0 rows affected (0.02 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> alter table artist engine=innodb;
Query OK, 0 rows affected (0.02 sec)
Records: 0 Duplicates: 0 Warnings: 0
查看当前的数据文件为:
[root@localhost Idx]# ls
album.frm album.ibd ar
(责任编辑:IT)
在使用Innodb引擎时将要面对两种表空间的管理选择的问题,Innodb有两种管理表空间的方法: 1. 共享表空间(也可以拆分成多个小的表空间) 2. 独立表空间每一个表有一个独立的表空间。 我个人推荐使用独立表空间。在性能和运维上独立表空间比共享的表空间有很多优势。下面我将分别说明一下两种表空间管理的特点。 共享表空间: 优点: 可以放表空间分成多个文件存放到各个磁盘上(表空间文件大小不受表大小的限制,如一个表可以分布在不同步的文件上)。数据和文件放在一起方便管理。 缺点: 所有的数据和索引存放到一个文件中以为着将有一个很常大的文件,虽然可以把一个大文件分成多个小文件,但是多个表及索引在表空间中混合存储,这样对于一个表做了大量删除操作后表空间中将会有大量的空隙,特别是对于统计分析,日值系统这类应用最不适合用共享表空间。 我们知道共享表空间管理会出现表空间分配后不能回缩的问题,当出现临时建索引或是创建一个临时表的操作表空间扩大后,就是删除相关的表也没办法回缩那部分空间了。我们存在磁盘监控时,也许就报警不断了,但实际上MySQL还可以运行良好。另外,当磁盘上占用较多时性能也不是太好。 这种情况处理只能是是建一个新的Slave从主库上Dump出来,然后在Dump到从库中,动作较大。 对于InnoDB Hot Backup备份的操作(或是直接冷备),每次需要CP的文件比较大。如果现在有180G的表空间,但实际数据只有50多G,那么我们将面对每次需要拷180G的数据。 这种方式也许mysqldump是一个好的处理方式了。 独立表空间: 在配置文件(my.cnf)中设置: innodb_file_per_table 优点: 1. 每个表都有自已独立的表空间。 2. 每个表的数据和索引都会存在自已的表空间中。 3. 可以实现单表在不同的数据库中移动。 4. 空间可以回收(除drop table操作处,表空不能自已回收) a) Drop table操作自动回收表空间,如果对于统计分析或是日值表,删除大量数据后可以通过:alter table TableName engine=innodb;回缩不用的空间。 b) 对于使innodb-plugin的Innodb使用turncate table也会使空间收缩。 c) 对于使用独立表空间的表,不管怎么删除,表空间的碎片不会太严重的影响性能,而且还有机会处理。 缺点: 单表增加过大,如超过100个G。 对于单表增长过大的问题,如果使用共享表空间可以把文件分开,但有同样有一个问题,如果访问的范围过大同样会访问多个文件,一样会比较慢。对于独立表空间也有一个解决办法是:使用分区表,也可以把那个大的表空间移动到别的空间上然后做一个连接。其实从性能上出发,当一个表超过100个G有可能响应也是较慢了,对于独立表空间还容易发现问题早做处理。 备份: InnoDB Hot Backup(冷备)的表空间cp不会面对很多无用的copy了。而且利用innodb hot backup及表空间的管理命令可以实现单现移动。 监控: 可以更好从系统上监控数据的大小,每个表的大小。 另外推荐使用独立表空间的原因: 从性能上对比共享表空间和独立表空间: 共享表空间在Insert操作上少有优势。其它都没独立表空间表现好。这里也有一个TIPS当启用独立表空间时,请合理调整一下:innodb_open_files 。 从Linux系统处理上出发: 文件系统fsync一大片更新数据,对系统io冲击较大。若分隔成多个小数据fsync,能够减少对读的影响。 同时从mysql代码,发现mysql保证两次fsync之间至少有20ms的sleep,这样的话,若将一次fsync变成多次小数据操作,应该能够减少慢查询的比例。所以对于大量更新操作的系统不太适合用共享表空间。 ========================================================================================== 修改为独立表空间: 1.查看当前表空间情况:
mysql> show variables like '%per_table';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| innodb_file_per_table | OFF |
+-----------------------+-------+
1 row in set (0.00 sec)
表示当前是共享表空间。
也可以通过观察含有innodb类型的表的文件来了解:
[root@localhost Idx]# pwd
/home/mysql/data/Idx
[root@localhost Idx]# ls
album.frm artist.frm db.opt Track.frm Track.MYD Track.MYI
想要将共享表空间转化为独立表空间有两种方法:
1.先逻辑备份,然后修改配置文件my.cnf中的参数innodb_file_per_table参数为1,重启服务后将逻辑备份导入即可。
2.修改配置文件my.cnf中的参数innodb_file_per_table参数为1,重启服务后将需要修改的所有innodb表都执行一遍:alter table table_name engine=innodb;
使用第二种方式修改后,原来库中的表中的数据会继续存放于ibdata1中,新建的表才会使用独立表空间
mysql> show variables like '%per_table';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| innodb_file_per_table | ON |
+-----------------------+-------+
1 row in set (0.00 sec)
查看指定库中存储引擎为INNODB的表:
mysql> SELECT
-> `TABLES`.TABLE_SCHEMA,`TABLES`.TABLE_NAME,`TABLES`.`ENGINE`
-> FROM information_schema.`TABLES`
-> WHERE `ENGINE`='INNODB' AND TABLE_SCHEMA='Idx';
+--------------+------------+--------+
| TABLE_SCHEMA | TABLE_NAME | ENGINE |
+--------------+------------+--------+
| Idx | album | InnoDB |
| Idx | artist | InnoDB |
+--------------+------------+--------+
2 rows in set (0.00 sec)
mysql> alter table album engine=innodb;
Query OK, 0 rows affected (0.02 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> alter table artist engine=innodb;
Query OK, 0 rows affected (0.02 sec)
Records: 0 Duplicates: 0 Warnings: 0
查看当前的数据文件为:
[root@localhost Idx]# ls
album.frm album.ibd ar
(责任编辑:IT) |