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....  但是这样做可能会造成数据不一致性，除非你本身数据文件是一致的，或是redo  log也备份了。
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 because InnoDB 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存储引擎的索引的一些疑问， 谁对这部分有深刻理解， 请说说自己的见解，欢迎讨论......