innodb的数据存储

对于innodb的数据存储文件,首先要解决两个概念性的问题: 共享表空间以及独占表空间。(innodb引擎与MYISAM引擎的区别很大。特别是它的数据存储方式等.)

1、共享表空间和独占表空间介绍

共享表空间以及独占表空间都是针对数据的存储方式而言的。

共享表空间:  每一个数据库的所有的表数据,索引文件全部放在一个文件中,默认这个共享表空间的文件路径在data目录下。 默认的文件名为:ibdata1  初始化为10M。

独占表空间:  每一个表都将会生成以独立的文件方式来进行存储,每一个表都有一个.frm表描述文件,还有一个.ibd文件(这个文件包括了单独一个表的数据内容以及索引内容)。


2、共享表空间和独占表空间的区别

共享表空间:
优点:
1)可以放表空间分成多个文件存放到各个磁盘上(表空间文件大小不受表大小的限制,如一个表可以分布在不同的文件上)。

所以其大小限制不再是文件大小的限制,而是其自身的限制。从Innodb的官方文档中可以看到,其表空间的最大限制为64TB,也就是说,Innodb的单表限制基本上也在64TB左右了,当然这个大小是包括这个表的所有索引等其他相关数据。

2)表数据和表描述放在一起方便管理。 

缺点:
1)所有的数据和索引存放到一个文件中,将有一个很常大的文件,虽然可以把一个大文件分成多个小文件,但是多个表及索引在表空间中混合存储,这样对于一个表做了大量删除操作后表空间中将会有大量的空隙,特别是对于统计分析,日志系统这类应用最不适合用共享表空间。


独立表空间(在配置文件(my.cnf)中设置innodb_file_per_table=1):

优点:
1)每个表都有自已独立的表空间。
2)每个表的数据和索引都会存在自已的表空间中。
3)可以实现单表在不同的数据库中移动。
4)空间可以回收。

对于使用独立表空间的表,不管怎么删除,表空间的碎片不会太严重的影响性能,而且还有机会处理(表空不能自已回收),处理方式如下:
Drop table操作自动回收表空间

如果对于统计分析或是日志表,删除大量数据后可以通过:alter table TableName engine=innodb;回缩不用的空间
对于使innodb-plugin的Innodb使用turncate table也会使空间收缩
5)使用独占表空间的效率以及性能会更高一点。

缺点:
1)单表增加过大,如超过100个G:

当使用独享表空间来存放Innodb的表的时候,每个表的数据以一个单独的文件来存放,这个时候的单表限制,又变成文件系统的大小限制了。

3、共享表空间以及独占表空间之间的转化

修改独占空表空间配置,以下几个参数必须在一起加入

innodb_data_home_dir = "/usr/local/mysql/var/"  数据库文件所存放的目录

innodb_log_group_home_dir = "/usr/local/mysql/var" 日志存放目录

innodb_data_file_path=ibdata1:10M:autoextend  设置配置一个可扩展大小的尺寸为10MB的单独文件(共享数据文件),名为ibdata1。没有给出文件的位置,所以默认的是在MySQL的数据目录内(如 /db/mysql/ibdata1)。

innodb_file_per_table=1  是否使用共享以及独占表空间(1 为使用独占表空间,0 为使用共享表空间)


innodb_file_per_table 通过这个参数来实现的转化,如果为OFF说明所使用的是共享表空间【默认情况下,所使用的表空间为共享表空间】

innodb_file_per_table值来进行修改即可,但是对于之前使用过的共享表空间则不会影响,除非手动的去进行修改


注意:

InnoDB不创建目录,所以在启动服务器之前请确认”所配置的路径目录”的确存在。

做数据的移植以及备份时,要注意数据文件的完整性.


当你启用了 innodb_file_per_table,表被存储在他们自己的表空间里,但是共享表空间仍然在存储其它的 InnoDB 内部数据:

  • 数据字典,也就是 InnoDB 表的元数据
  • 变更缓冲区
  • 双写缓冲区
  • 撤销日志

其中的一些在 Percona 服务器上可以被配置来避免增长过大的。例如你可以通过 innodb_ibuf_max_size 设置最大变更缓冲区,或设置 innodb_doublewrite_file 来将双写缓冲区存储到一个分离的文件。

MySQL 5.6 版中你也可以创建外部的撤销表空间,所以它们可以放到自己的文件来替代存储到 ibdata1。可以看看这个文档

当 MySQL 出现问题通常我们需要执行的第一个命令是:

 
   
  1. SHOW ENGINE INNODB STATUS/G

这将展示给我们一些很有价值的信息。我们从** TRANSACTION(事务)**部分开始检查,然后我们会发现这个:

 
   
  1. ---TRANSACTION 36E, ACTIVE 1256288 sec
  2. MySQL thread id 42, OS thread handle 0x7f8baaccc700, query id 7900290 localhost root
  3. show engine innodb status
  4. Trx read view will not see trx with id >= 36F, sees < 36F

这是一个最常见的原因,一个14天前创建的相当老的事务。这个状态是活动的,这意味着 InnoDB 已经创建了一个数据的快照,所以需要在撤销日志中维护旧页面,以保障数据库的一致性视图,直到事务开始。如果你的数据库有大量的写入任务,那就意味着存储了大量的撤销页。

如果你找不到任何长时间运行的事务,你也可以监控INNODB STATUS 中的其他的变量,“History list length(历史记录列表长度)”展示了一些等待清除操作。这种情况下问题经常发生,因为清除线程(或者老版本的主线程)不能像这些记录进来的速度一样快地处理撤销。


innochecksum 工具 分析ibdata1 共享表空间的信息。

猜你喜欢

转载自blog.csdn.net/nawenqiang/article/details/80010675