表空间TABLESPACE在主流数据库的存储设计中，通常出现在逻辑存储设计的最底层ORACLE 和MYSQL中，表空间再往下走，就直接指向了文件系统（或者ASM）上的一个或者一组文件集合。DB2 （下面全部指ZOS版）在表空间和物理文件中，还有一层存储空间组（SG），DB2 的在表空间定义的时候指定其使用的SG，SG定义的时候，指定其使用的物理卷组。当表空间定义的时候，会在卷组里产生对应的文件。这一层可以说既是物理文件的集合,逻辑上是数据表的集合,承上启下的重要位置。
我个人比较喜欢在做数据库存储设计的时候，从表空间这里开始。因为无论是哪种数据库，表空间的敲定，就决定了数据库表、表的数据文件存储上的隔离度。整个系统定几个表空间？哪些表？哪些索引？以什么样的方式抽象、归类并存放于不同的表空间，大体上也就对整个数据库存储体系的设计打下基础。对于ORACLE，存储在不同的表空间，一定是意味着放在不同的文件的。然而，这也是ORACLE在文件层面上隔离一个表，唯一的手段。就是说，我要两个表，存在不同的文件，我一定要让他存在两个不同的表空间。因为ORACLE的表空间下，虽然可以挂多个数据文件，DBA却不能明确的敲定，我的某个表使用哪个文件。非常神奇的事情是，ORACLE确是一个支持一个表，存储在多个表空间上的数据库。DBA可以精确的指定分区表的某一个分区使用哪个表空间。同一个表的不同分区，可以使用不同的表空间。如果想让不同的分区，在不同的文件。这是在ORACLE上唯一的实现方式。
在文件上隔离分区，这件事情对于一个纯粹的ORACLE DBA来说，可能稍微有点莫名其妙。但是，如果一个尝试过，把DB2 上的分区表，迁移到ORACLE上来的DBA，这件事情的思路就变得非常好理解。要想在DB2 上定义一个分区的表，那DBA必须给DB2 定义一个表专用的表空间。并且要清楚的告诉DB2，这个表空间上会有多少的分区。在未来，这个表建立以后，DB2会为这个表准备和分区数一样的文件数，并且文件和分区一一对应。在DB2上，分区的表，天然就是文件隔离的，不同的分区，自然而然的使用者不同的数据文件。MYSQL更像是在其中搞了个折中方案，折中后那更像ORACLE,或者MYSQL更想做成ORACLE的样子。
可以看出ORACLE和IBM对表空间的理解是不同的。ORACLE对表空间的理解，更像是一个物理文件集合后的逻辑地址。这里集合是非常非常重要的。表空间像是村庄，它里面有好多好多房子（磁盘上的文件），住了好多好多人（数据表或者其他对象）。至于里面怎么住，哪个人（分区）住哪个房间（文件），用户不要管，反正让你可以住就好了。而IBM的表空间，更像是一栋房子。一家人（一个表）就住一栋房子（表空间），不同的家人（分区），可以用不同的房间（文件）。由很多很多表空间组成的SG，才更像一个是村庄。
对表空间的理解不同，其实可以衍生到对分区概念上面。我很认同一个理念就是，作为数据库的使用者而言，分表和分区，是一样的。其实分表的概念，很多时候是出自早期开源MYSQL的版本上面。为什么要分表的原因，也很简单，因为早期的MYSQL版本不支持分区。数据库分区到底是一个逻辑隔离的概念，还是一个有物理隔离的需求？IBM对于DB2的处理就很明确，不同的分区，就是不同的物理文件。而ORACLE选择了一种很模糊的态度，也就是通常情况下，ORACLE认为分区只是逻辑隔离，毕竟不同的分区还是在不同的段（SEGMENT）上面的。但是，它毕竟留了一条路，就是前文说的，DBA可以把不同的分区存在不同的表空间上。粗暴的解释，有一家两个人，对村长说，我们不要住在一栋房子离。村长说，不行，是随机分配的。但是，我可以让你住到别的村子里去。
DB2能不能住到别的村子去呢?答案是可以,不同的分区也可以存储到不同的SG上面去。这种做法我从来没有使用过,但是可以想象到的好处是显而易见的,比如不同物理存储介质提高并发性能这种。我可以隐隐约约的感觉到,这种不同的设定,大概还会与ZOS,ASM以及普通linux的文件系统之间的差异存在一些关联。比如说,文件的概念。但是,这个内容,并不是很了解,也可能是我想多了。
ORACLE在11g的时代，还比较推荐用户，在不同功能的数据库表，划分在不同的数据库表空间。另外也推荐，数据表，和表的索引使用的表空间不要放在一起。随着大表空间的兴起，以及12C、18C往后的版本来看。ORACLE越来越推从使用者不要关心存储。ORACLE试图给DBA一种气质，ORACLE很牛，你把所有的东西都给我一个表空间，文件怎么放，ORACLE来搞定。你把乱七八糟的东西，都往我一个大的表空间里堆，也没什么大不了的。继续以房子比喻,DB2给你一个毛胚房,希望你自己安排的特别适合自己。ORACLE则励志于做精装,你住就好了。
关于MYSQL的存储引擎就非常有意思的来认知表空间。此处的MYSQL主要说的是InnoDB的存储引擎，就我个人感觉上。MYSQL在被ORACLE收购以前，或者说，它的主要存储引擎还不是InnoDB的时代，我觉得MYSQL都还不算一个真正合格的OLTP系统的存储引擎。此处先不多说。MYSQL有一个默认的共享表空间，名为ibdata1，这个表空间下自然可以挂很多很多文件。可以自动增长。所有InnoDB存储引擎的表，都会记录到该共享表空间里去，看到这里是不是很有ORACLE的气质。然而，MYSQL有一个参数，叫做innodb_file_per_table，这个参数设为ON的时候，每个InnoDB存储引擎的表都可以产生一个独立的表空间。NANI？是不是有一种一秒钟变成DB2的感觉。不对，还没看分区对不对。再看分区，更神奇了，MYSQL一旦使用了分区之后。表不再由一个ibd文件组成了，而是由建立分区时的各个分区ibd文件组成。简直就是DB2 存储的翻版有没有。看到这个设定之后，我个人觉得，大型的OLTP系统，还是老老实实的innodb_file_per_table=ON，毕竟MYSQL自己一副没底气的样子。那么使用的DBA，还是要更加精细一点。在DB2 迁移往ORACLE的过程中，经常会查资料或者问，这个表堆在一起有没有问题，那个这么粗放有没有性能不好。无论ORACLE官方还是民间资料都显得十分有底气，答案都是没有问题。而关于MYSQL表空间都用默认表空间好不好，无论是书籍还是各类资料，随便查查，都有这样那样不好的可能性，什么文件碎片、性能问题等等。总之感觉，让人用的不会那么放心。好吧，以上内容就是关于表空间的一些总结，就此。