我已經繼承了一個公司應用程序，每個「對象」使用58個表，並且應用程序可以有N個對象。我們正在爲應用程序安裝75-100個對象，即4300-5000個表。1000個表或mysql的多個實例？
我們正在試圖找出是做的，我們要使用一個數據庫和每個對象前綴的表名，或每個對象使用一個數據庫（應用程序支持）。唯一的區別是每次安裝應用程序時，如果我們要爲每個數據庫執行操作，則需要在不同端口上添加更多的mysql實例。
有沒有人做過類似的事情？在數據庫中是否有任何問題（管理層以外）有4000多個表？
編輯
感謝您的更新。至於一堆評論
1）公司付出的很好......我不會愚蠢的不要這份工作。我只希望寫出優秀的代碼將我的銀行賬戶中的$ $$
2）我們的客戶對產品感到滿意。我們考慮過重新編寫它，但除了成本之外，我們會錯過市場。雖然結構糟糕，但該應用程序的效果比大多數客戶都要好。
3）對象不是最好的術語......它不像對象/類，而是應用程序內部的對象。我想我可以只說鬥。
很難說沒有看到實際的模式（以及爲什麼地球上的某個對象可能需要58表），但是如果您需要連接這些表，您需要將它們保存在一個數據庫中。
在一個數據庫中有很多MyISAM表意味着一次使用它們意味着需要有大的table_cache。
如果你重複58次表格100次，我建議規範化規則已被踐踏。您的公司不太可能會重新審視此產品的架構設計，但我會根據您提供的信息推薦它。
不要讓它分佈數據庫更糟。延遲如何提供幫助？
MySql將每個表格存儲爲一個文件，除了操作系統和硬盤驅動器之外，沒有任何限制。但是，有一個原因並沒有經過討論 - 擁有數千個表幾乎肯定是錯誤的事情，您的數據庫模式可能非常需要重新設計。
將每個tabke作爲一個文件：不是，InnoDB例如將所有數據存儲在單個文件中，除非設置了特定的選項。 – shylent 2009-12-30 16:03:59
奇怪的是，我已經看到了這個類型的應用程序，我可以告訴你這樣做是最好的東西重新編寫應用程序。停止銷售應用程序，直到可以重新考慮設計不包含每個對象58個表。
我曾爲一家實施類似於您所談論的事情的公司工作。我們使用的是一種名爲RAMCO的產品，並且以任何方式實施，我們選擇將所有表保存在單個數據庫中。我們選擇這種方法有多種原因（包括更簡單的管理，備份，複製和集羣）。有趣的是，當你有這樣一個不連貫的數據模型時，你放入它的實際數據量並不比你放入不同的模型更多。出於這個原因，我們的備份大約是12GB未壓縮的。就引擎而言，它可以處理很多表格。
這就是說，我同意迄今爲止的所有其他答案，您的公司應該肯定會重新考慮他們的數據架構（或者如果我是你，我會重新思考我是否真的想爲一家可以實施類似的東西）。就我而言，該合作者拒絕放棄該產品，所以我找到了其他工作。
如果您可以保證表的數量不會無限制地增加，那麼擁有相當大數量的表是沒有問題的。
真的是主要的問題是表緩存（它應該真的比表總數大，除非你想要性能吸）和引擎和操作系統的限制。
我們經常使用MyISAM，每臺服務器有2000多個表，如果您已經調整並測試了它與該卷一起工作，則沒有特定的問題。
確保您使用預定數量的表進行性能測試。開桌子可能很昂貴，所以請確保你不要做太多的事情。
當你關閉一個表時，一些引擎（MyISAM）會拋出一些緩存的數據（只有關鍵塊），如果你定期關閉它們，這是非常糟糕的。
根據選項，您的引擎可能需要一個或多個文件描述符，每個打開的表。通常（在Linux上）mysql應該使用ulimit正確調整最大數量，但在某些情況下可能不會。
在某些時候，您可能會遇到os範圍的限制（默認情況下，我認爲在某些Linux版本中爲32k），並且必須通過sysctl或其他調整來增加它。
一篇不錯的文章，討論您所問的同一問題： http://bit.ly/5Zs9aC – 2009-12-30 15:30:11
您可以在數據庫中擁有大量表格，但特定產品具有特定的限制。給mysql看到這篇優秀的文章： http://www.askbjoernhansen.com/2008/02/14/10000_tables_in_one_mysql_database.html 是否有可能您的precdessor創建如此多的表作爲一種分區形式？它是一個對象，像一個分散在多個表（垂直，分佈的列）的單個客戶，還是更多地是整個客戶集合被劃分爲多個表（水平的，分佈的行）？ – 2009-12-30 15:30:50
雖然我無法提供答案，但我可以提供我的同情！ – 2009-12-30 15:39:26