MYSQL IBDATA

mysql中只有ibdata文件如何恢复数据库？

你以为是Oracle数据库吗？除非非常重要，用工具直接读里面的一些内容吧，不知道有这样的工具没，前提是InnoDb用的是共享表空间

只有ibdata1可以恢复的，不过需要非常了解数据库的结构

对于innodb的数据文件，严格来说分两类，一种是系统表空间的数据文件默认命名也就是ibdata1，这里记录了所有其他表空间（当设置innodb_table_per_file=1）和相关表的信息，还有回滚段和一些其他相关信息。
如果创建表时，innodb_table_per_file=1，那么你的这个表的数据信息（也就是每行数据）主要是存放在.ibd文件里面，而此时在ibdata1这个文件里面也会记录下你新创建了一个表，而且是独立表空间
如果创建表时，innodb_table_per_file=0，那些表的所有相关也会存放在ibdata1里面。
当然无论innodb_table_per_file取值，所有表的定义信息都是独立的文件<table>.frm

所以在你想从数据文件恢复时：
1.如果恢复独立表空间.ibd,那是极其困难的，除非你的系统表空间里面记录了你的这个独立表空间的相关信息，否则肯定没戏。即使有，也不一定能成。
2.如果你是恢复系统表空间ibdata1，那么这还有一点希望，将原先的ibdata1移走，将新的ibdata1移入，然后在配置文件中将数据文件的大小改为新移入的数据文件大小datafile_name:size....但是这样做可能会造成数据不一致性，除非你本身数据文件是一致的，或是redolog也备份了。
3.如果你ibd,ibdata都有？ redo 也有? 那这就相当于一个全备了

另外xtrabackup貌似提供了什么库级、表级备份，我没用过，不过它的实现原理肯定是那些表空间、表的元数据信息全部被记录下来，所以也就能进行恢复

刚才尝试了一下恢复系统表空间，关闭mysqld，拷贝数据文件，替换数据文件，开启新实例，能成功。

在InnoDB中有两种形式的索引，一种是cluster形式的主键索引（primary key），另外一种是和其他存储引擎（如MyISAM引擎）存放形式基本相同的普通b-tree索引，这种形式的索引在InnoDB存储引擎中被称为secondary index。主键索引和secondary index的区别在于叶子节点。在primary key中，叶子节点存放的是表的实际数据，不仅仅包含主键字段的数据，还包括其他字段的数据，整个数据以主键有序的排列。而secondary index则和其他普通的b-tree索引没有太大的差异，只是在叶子节点除了存放索引键的相关信息外，还存放了InnoDB的主键值。
所以，在InnoDB中如果通过主键来访问数据效率是相当高的。而如果通过secondary index来访问数据的话，InnoDB首先通过secondary index的相关信息及相应的索引键检索到叶子节点，然后通过叶子节点中的主键值和主键索引来获取相应的数据行。

接着也去查了下手册，没找到专门介绍索引的章节（谁知道，请告诉我一下），但是在调优章节也算是提到了这两种索引：
For InnoDB,a secondary index might cover the selected columns even if the query also selects the primary key becauseInnoDB stores the primary key value with each secondary index.



1.主键索引和secondary index（应该可以翻译成二级索引吧）的唯一区别就是在于叶子节点，都是采用b-tree实现的，这个我没什么疑问。

2.主键索引的叶子节点不仅仅包含主键字段的信息，还包括其他非主键的所有字段信息。这么做值得吗？ 这得浪费多大的存储空间啊？索引文件都可能比数据文件要大啊（索引文件除了叶子节点数据外，还有根节点数据，分支节点数据）。 估计设计者是想用空间换时间来提高效率。

3.secondary index， 除了存放索引键之外，还存放InnoDB的主键值。利用secondary index的时候，按照作者的意思是先扫描secondary index的索引文件，找到目的叶子节点之后，在利用这个叶子节点上的主键值去扫描主键索引，然后找到这行。 这不相当于扫描了两个索引文件吗？ 这效率会要降低多少啊？ MySQL有没有提供一个定位到具体某一行的信息啊？ 就像oracle中的rowid一样，这样在时间和空间之间有个更好的折中考虑。

以上就是自己对InnoDB存储引擎的索引的一些疑问， 谁对这部分有深刻理解， 请说说自己的见解，欢迎讨论......