關於MySQL資料庫分表問題

最近需要做分表，搜集了一些相關資料，發現分表所帶來的一系列問題（如列表顯示、資料搜尋），代價很高且複雜，且擴充性與後期維護性也很複雜！

搞得不敢用分表了，在想MySQL內建資料分割函數，為什麼都不用呢，偏偏用複雜的分表問題，表示很不解。

如果按取餘數來分表，以後再增加表就很麻煩，用一致性雜湊演算法倒是個好方法，但都面臨同一個難題就是查詢問題，不知道大家在實際項目中是怎麼處理分表問題的？不想用MySQL內建的分表功能，它不是InnoDB的。

回複內容：

最近需要做分表，搜集了一些相關資料，發現分表所帶來的一系列問題（如列表顯示、資料搜尋），代價很高且複雜，且擴充性與後期維護性也很複雜！

搞得不敢用分表了，在想MySQL內建資料分割函數，為什麼都不用呢，偏偏用複雜的分表問題，表示很不解。

如果按取餘數來分表，以後再增加表就很麻煩，用一致性雜湊演算法倒是個好方法，但都面臨同一個難題就是查詢問題，不知道大家在實際項目中是怎麼處理分表問題的？不想用MySQL內建的分表功能，它不是InnoDB的。

菜鳥說下個人的理解哈，個人覺得這個還是要看自己具體業務的需求。比如一些曆史資料或者大日誌資料，這些資料如果操作性要求不高的話，可以嘗試分表。之前處理話務中心業務，每天幾百萬的日誌資料，就用的mysql內建的merge引擎分表，業務中主要是單做展示的用途，系統感覺啟動並執行還OK。不過這種用法貌似現在已經不推薦了。現在用的是分區表，資料量也不算大，單表差不多快1000W的資料，效能同樣ok。

應該思考一下分表的初心。
分表解決了什麼問題，沒有解決什麼問題。

mysql內建的分表貌似最大隻能分1024張表，擴充還是有局限性

