一、MySQL中一個庫中表數量是否有限制

1.限制那肯定是有的，因為系統數據庫的表結構信息存儲表，字段為：ID INT UNSIGNED 類型，非常多42億多一點，但肯定不會超過；

2.主要是文件系統，對同時打開多少個文件有限制性的：2048，但是可以修改內核參數

3.拆分過多最大的壞處，體現在：數據庫的維護上面；

4.數據量沒達到一定程度，且業務需求不需要，例如：新聞主題表，幾百G正常，就可能不必要拆分，但是像新浪這樣的公司就必須要拆分。換句話而言就是要看數據量、業務發展趨勢、數據的存取需求、數據訪問的并發度等綜合而考慮；

5.拆分，必然對程序操縱數據的復雜度增大了，為此不得不搞一個通用的數據層，其實在數據量、并發不高、壓力不大等情況下，是浪費資源，以及降低處理效率的，只有大數據量、高并發等場景下才是提高；

6.拆分之后，還可能帶來隱患點，比如通用數據層，必須考慮單點等問題，同時也可能帶來問題排查的難度；

7.大數據量、高并發等場景，準確說應該一般是：垂直拆分+水平拆分，肯定是提供性能、系統負載能力、支持業務增量等；

所以，綜合建議大家慎重分析自己所在公司的業務模型，數據增長趨勢，技術實力等綜合考慮，才是最穩妥的，不要把簡單的事情搞復雜了。

延伸閱讀：

二、id的一些典型的類型

整型：整型通常來說是優異的選擇，這是因為整型的運算和比較都很快，而且還可以設置 AUTO_INCREMENT 屬性自動遞增。ENUM 和 SET：通常不會選擇枚舉和集合作為 id，然后對于那些包含有“類型”、“狀態”、“性別”這類型的列來說是挺合適的。例如我們需要有一張表存儲下拉菜單時，通常會有一個值和一個名稱，這個時候值使用枚舉作為主鍵也是可以的。字符串：盡可能地避免使用字符串作為 id，一是字符串占據的空間更大，二是通常會比整型慢。選用字符串作為 id 時，還需要特別注意 MD5、SHA1和 UUID 這些函數。每個值是在很大范圍的隨機值，沒有次序，這會導致插入和查詢更慢：插入的時候，由于建立索引是隨機位置（會導致分頁、隨機磁盤訪問和聚集索引碎片），會降低插入速度。查詢的時候，相鄰的數據行在磁盤或內存上上可能跨度很大，也會導致速度更慢。

如果確實要使用 UUID 值，應當移除掉“-”字符，或者是使用 UNHEX 函數將其轉換為16字節數字，并使用 BINARY(16)存儲。然后可以使用 HEX 函數以十六進制的方式進行獲取。UUID 產生的方法有很多，有些是隨機分布的，有些是有序的，但是即便是有序的性能也不如整型。