Mysql Innodb的兩種資料表空間方式

要說資料表空間，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能夠出現真正意義上資料表空間的概念，更加自由的規劃資料檔案。