經過試驗，得出的結論是mysql沒有分割槽分表這兩個概念，透過partition同時可以進行我們傳統意義上的分割槽和分表。不需要要我們手動建立N個子表再透過總表merge子表，也無需我們在上層程式碼透過什麼求餘求hash來決定操作哪個物理子表，直接使用我們建立的表，mysql最佳化器就可以自動幫我們分析使用哪個子表了。為了證明我的結論，假設partition只是所謂的分割槽，那麼所有的資料都是在同一張表上。

我建立了這樣一張表：

可以看到在資料夾內生成了兩個子表：

注意，這張總表沒有主鍵也沒有其它索引，那麼透過innodb的特性可以知道，當沒有索引的時候innodb使用的不是行級鎖而是表級鎖。

然後我插入了8條記錄：

然後分別查兩個分割槽的資料：

為了證明這兩個分割槽的資料不是在同一個表上的我們開啟兩個客戶端分別執行：

根據innodb的特性當沒有索引的時候innodb使用的不是行級鎖而是表級鎖，可以看到當我們顯示開啟排他鎖但是我們沒有提交事務而這兩個事務都沒有阻塞，說明什麼？說明透過partition建立的子表是真真實實存在的不同的物理表。同時也說明在增刪改的時候即使我們只操作總表，也是可以生效的，而不用再像傳統意義上的在高階語言上用程式碼處理該訪問哪個子表至於是不是順序I/O不知道怎麼檢驗。但是至少從發生的現象得出網上說的partition只是分割槽的說法是不正確的。個人認為mysql已經沒有傳統意義上的分割槽和分表的劃分了，都歸在一起了。

首先得理解分割槽和分表有什麼差別

分割槽是邏輯上的 但實際各分割槽的存放是可以物理隔離的 看上去跟分表一樣 但各分割槽的資料字典是統一的 就是分割槽表的資料字典 所以分割槽除了資料分散以為 最主要的是字典集中 在跨分割槽、多分割槽查詢時較分表的形式要簡潔 分割槽只能在一個庫裡實現

分表是不同的表 可以跨庫分佈 這些表本質上是互相獨立的 其對外的統一是靠應用層實現的 分表更徹底 但管理更復雜

所以在一般情況下 分割槽表已經能很好的實現資料分散。但由於公用資料字典且不能跨庫 所以在高併發場景下仍然受限 於是分散式的分表方案應運而生

回到問題 PARTITION就是分割槽 至於看到不同分割槽有不同的資料檔案 那是底層實現問題 分割槽表只有一個FRM檔案 足以說明它是一張表（分割槽表）而不是很多張表（分表）