要說表空間，Mysql的表空間管理遠遠說不上完善。換句話說，事實上Mysql根本沒有真正意義上的表空間管理。Mysql的Innodb包含兩種表空間文件模式，默認的共享表空間和每個表分離的獨立表空間。只要在my.cnf里面增加innodb_file_per_table=1就可以從共享表空間切換到獨立表空間。當然對於已經存在的表，則需要執行alter table MY_TABLE engine=innodb命令遷移數據。
共享表空間方式
由於是默認的方式，就暫且理解為Mysql官方推薦的方式。相對而言所有的數據都在一個（或幾個）文件中，比較利於管理，而且在操作的時候只需要open這一個（或幾個）文件即可，相對來說代價很低。
但問題是在數據達到以G為單位來計算的時候優劣逆轉。一個大小驚人的文件很不利於管理，而且對於一個如此巨大的文件來說，讀寫它需要耗費的資源一樣巨大。更加令人費解的是，MySQL竟然將索引和數據保存於同一個文件中，索引和數據之間尚存在資源爭用，不利於性能的提升。你當然可以通過innodb_data_file_path的配置規划多個表空間文件，但MySQL的邏輯是“用滿后增加”，僅僅是一個文件的拆分而已，不能從根本上分離數據和索引。
之前曾經遭遇到700G以上的表空間文件，而且更加讓人郁悶的是對於如此大的文件還在以每天數G的數量增加。由於無法停機，即便是拷貝一下也要花費差不多一夜，只能眼睜睜看着它繼續增大而毫無保守可行的辦法。
獨立表空間方式
相對而言對立表空間每個表都有獨立的多個數據文件，而且做到了索引和數據的分離。多個小文件之間很方便的完成跨數據庫甚至跨硬件的數據拷貝和遷移。相對來說靈活性很好。
這樣做同樣帶來另一個方面的問題。當數據庫中的表數量達到一定級別時，每次操作所涉及的文件過多，如果按照默認Centos的ulimit -n = 1024的話，僅僅只能保證同時打開256個表以內，這在習慣上“拆庫拆表”的MySQL數據結構上很難達到要求。尚且這種數據文件的利用率不算很高，當大量“不高”的文件集中起來，浪費的空間也很驚人，更何況最后可能出現的狀況不是“一堆K級別的小文件”而是“一堆G級別的大文件”，有點適得其反的意思。你自然可以聯想到分區表，又是一個“僅僅做文件拆分而已”，多個分區文件缺一不可。
之前同樣遇到過這個問題，MySQL連接大的狀況下大量的timeout，但主機負載還算可以，查了一圈才知道是open files限制的問題，限制一修改，負載變得驚人，但連接數卻又提升的不多。
總之，兩種方法各有所長，部分互補，但都不是解決問題的終極方案。期待MySQL能夠出現真正意義上表空間的概念，更加自由的規划數據文件。