MySQL 中一個庫中表數量是否有限制？表太多是否影響數據的性能？比如要把一張表拆成 1024 張，對於每個表的性能的影響是什麼？這些影響需要考慮哪些因素？

02-04

1.限制那肯定是有的，因為系統資料庫的表結構信息存儲表，欄位為：ID INT UNSIGNED 類型，最多42億多一點，但肯定不會超過；

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

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

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

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

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

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

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

1. 如果是innodb,而且讀命中都是精準命中(即每次查詢都是WHERE XXX=x的查詢)，而分表後表文件都在同一張磁碟上，那麼分表意義不大。

2. 如果是myisam……你決定你的需求真的適合myisam嗎？myisam大多數情況最好別用……除了做純讀、批量插入的數據挖掘……

主要根據自己的業務場景，但總之，拆表是下下之選，能不拆就不拆，因為拆表後不僅僅涉及到資料庫，還涉及到代碼層面。只是，某些場景下，不拆不行。比如，無法避免的範圍查詢，如果不拆表，無法避免的全表掃描會因為單表基數過大（能夠通過冗餘欄位避免全表掃描的請無視，但就算冗餘欄位，如果不能通過冗餘欄位把基數降低到20%以下，索引失效，依然是All查詢）嚴重影響性能，所以，只能通過降低基數優化查詢速度。至於表數目，這個我真的不了解，但感覺單庫一千左右，影響應該不大(固態，機械硬碟應該要考慮磁碟碎片因素，特別是單表體積很大，插入頻繁的情形)。

PS：如果你的查詢都是cost級別，說白了就是類似主鍵的精確查詢，MySQL而言，千萬級別數據，也能夠達到50ms左右。

資料庫一張表的容量肯定是有限制的，不可能無限大，數據量越大對查詢效率肯定有比較大的影響。當我們想通過減少單張表的數據量來提高性能時一般通過水平分表或者垂直分表的方式來解決，表的數量得看當時的業務而決定。如果我要做一個秒殺優惠券綁券功能設計，表的數量可能會設計的比較多，但上限跟mysql的連接池有關係。比如我只是一般的水平分表的話，可以通過估計以後業務和規模量來分多少張表。一個庫一般表的數量是有限制的，太多肯定不好，一個庫的容量也有限制，但具體還的看業務，結合具體情況分析。