一、MySQL中一個(gè)庫中表數(shù)量是否有限制

1.限制那肯定是有的，因?yàn)橄到y(tǒng)數(shù)據(jù)庫的表結(jié)構(gòu)信息存儲(chǔ)表，字段為：ID INT UNSIGNED 類型，非常多42億多一點(diǎn)，但肯定不會(huì)超過；

2.主要是文件系統(tǒng)，對(duì)同時(shí)打開多少個(gè)文件有限制性的：2048，但是可以修改內(nèi)核參數(shù)

3.拆分過多最大的壞處，體現(xiàn)在：數(shù)據(jù)庫的維護(hù)上面；

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

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

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

7.大數(shù)據(jù)量、高并發(fā)等場景，準(zhǔn)確說應(yīng)該一般是：垂直拆分+水平拆分，肯定是提供性能、系統(tǒng)負(fù)載能力、支持業(yè)務(wù)增量等；

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

延伸閱讀：

二、id的一些典型的類型

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

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