开启了Innodb的innodb_file_per_table这个参数之后【innodb_file_per_table = 1】，也就是启用InnoDB的独立表空间模式，便于管理。此时，在新建的innodb表的数据库目录下会多出来一个.ibd这个文件。这个就是此时的数据文件了。mysql会把这个innodb表的数据存放在这个文件中。并且每个innodb表此时都会对应这么一个ibd文件。
看官方文档：
If innodb_file_per_table is disabled (the default), InnoDB creates tables in the system tablespace. Ifinnodb_file_per_table is enabled, InnoDB creates each new table using its own .ibd file for storing data and indexes, rather than in the system tablespace.
那么这样做有什么好处呢？
可以实现单表在不同的数据库之间移动。具体怎么移动呢？假设有两个数据库，一个test，一个tt。
InnoDB 默认会将所有的数据库InnoDB引擎的表数据存储在一个共享空间中：ibdata1，这样就感觉不爽，增删数据库的时候，ibdata1文件不会自动收缩，单个数据库的备份也将成为问题。通常只能将数据使用mysqldump 导出，然后再导入解决这个问题。共享表空间在Insert操作上少有优势。其它都没独立表空间表现好。当启用独立表空间时，请合理调整一 下innodb_open_files 的值。
-------------------------------------------------------------------------------
需要说明的是：
1、设置了独立表空间之后，如果改成了共享表空间，那么，此时如果执行表的插入操作，数据会存放在哪里呢？
对于之前已经存在了的表，还是存放在独立表空间。对于新建的表，就会存放在共享表空间了。
2、如果一开始用了独立表空间，后来改了innodb_file_per_table变量的值，改成独立表空间了，那么数据如何存储？
对于已经存在了的innodb引擎的表来说，数据还是存放在共享表空间的，而此时如果创建了新的表，那么就会在数据库的目录中多出一个.ibd的文件用于存储这个新表的数据。
总结上面的1、2，就是：原来的还是按照原来的方式存储。新的表按照新的规则来存储。
共享表空间方式（其表空间的最大限制为64TB）
由于是默认的方式，就暂且理解为Mysql官方推荐的方式。相对而言所有的数据都在一个（或几个）文件中，比较利于管理，而且在操作的时候只需要open这一个（或几个）文件即可，相对来说代价很低。
但问题是在数据达到以G为单位来计算的时候优劣逆转。一个大小惊人的文件很不利于管理，而且对于一个如此巨大的文件来说，读写它需要耗费的资源一样巨大。更加令人费解的是，MySQL竟然将索引和数据保存于同一个文件中，索引和数据之间尚存在资源争用，不利于性能的提升。你当然可以通过innodb_data_file_path的配置规划多个表空间文件，但MySQL的逻辑是“用满后增加”，仅仅是一个文件的拆分而已，不能从根本上分离数据和索引。
之前曾经遭遇到700G以上的表空间文件，而且更加让人郁闷的是对于如此大的文件还在以每天数G的数量增加。由于无法停机，即便是拷贝一下也要花费差不多一夜，只能眼睁睁看着它继续增大而毫无保守可行的办法。
独立表空间方式
相对而言对立表空间每个表都有独立的多个数据文件，而且做到了索引和数据的分离。多个小文件之间很方便的完成跨数据库甚至跨硬件的数据拷贝和迁移。相对来说灵活性很好。
这样做同样带来另一个方面的问题。当数据库中的表数量达到一定级别时，每次操作所涉及的文件过多，如果按照默认Centos的ulimit -n = 1024的话，仅仅只能保证同时打开256个表以内，这在习惯上“拆库拆表”的MySQL数据结构上很难达到要求。尚且这种数据文件的利用率不算很高，当大量“不高”的文件集中起来，浪费的空间也很惊人，更何况最后可能出现的状况不是“一堆K级别的小文件”而是“一堆G级别的大文件”，有点适得其反的意思。你自然可以联想到分区表，又是一个“仅仅做文件拆分而已”，多个分区文件缺一不可。
之前同样遇到过这个问题，MySQL连接大的状况下大量的timeout，但主机负载还算可以，查了一圈才知道是open files限制的问题，限制一修改，负载变得惊人，但连接数却又提升的不多。
总之，两种方法各有所长，部分互补，但都不是解决问题的终极方案。期待MySQL能够出现真正意义上表空间的概念，更加*的规划数据文件