我已經看到幾個論壇與這個問題，但他們沒有回答我想知道的一件事。我將首先解釋我的主題：多桌或單桌？
我有一個系統，其中多個用戶的每個日誌都輸入到數據庫（例如，用戶1登錄，用戶2登錄，用戶1進入用戶管理，用戶2更改密碼等）。所以我預計每個用戶每天會有100到200個條目。現在，我在單個表中進行查看，只需使用UserID進行過濾。
我的問題是，這是更有效？我應該使用單個表還是爲每個用戶創建一個表？
我很擔心，如果我使用一個表，系統可能有一定的難度過濾幾千項。我已經閱讀了一些優點和缺點，使用多個表格和一張表格，特別是關於更新表格的方法。
我也想知道哪一個更節省空間？多桌或單桌？
我會去只有一張桌子。我當然不希望每次將用戶添加到系統時都創建一個新表。你每天提到的條目數量真的不是那麼多的數據。
另外，在您的表的用戶列上創建一個索引以提高查詢時間。
只要您使用你從選擇字段的索引，你應該不會有什麼問題的速度（雖然指數慢寫，所以太多是一件壞事）。有數千個條目的表對於MySQL（或任何其他數據庫引擎）來說沒有任何意義。
創造了數千個表的開銷是差很多 - 說你要做出改變，以在用戶表中的字段 - 現在你不得不改變萬的表。
我們定期搜索對單個記錄@工作表有15萬行，因爲我們搜索字段建立索引，搜索時間在一秒鐘的很小部分。
如果你選擇這些記錄不使用主鍵，你用它來選擇這樣的領域創建一個索引：
CREATE INDEX my_column_name ON my_table(my_column_name);
那是最基本的形式。要了解更多信息，請查詢here
絕對是一張表。爲由應用程序創建的實體動態創建的表不會縮放。此外，您需要使用變量表名稱創建查詢，這使得調試和維護變得困難。 如果您有用於過濾的用戶標識的索引，對於數據庫來說，處理數百萬行並不是什麼大問題。
任何有價值的數據庫都會處理一張包含所有用戶信息的表格，而不會冒出任何汗水。單個表格絕對是正確的做法。
如果您使用了多個表格，則每次註冊新用戶時都需要創建一個新表格。您需要爲您查詢的每個用戶創建一個新的語句對象。這將是一個完整的混亂。
我會去一張桌子。通過userId上的索引，您應該可以輕鬆地擴展到數百萬行，而且幾乎沒有問題。
每個用戶的表可能更有效率，但它通常是糟糕的設計。每個用戶使用一個表的問題是，它很難回答其他類型的問題，比如「誰昨天在用戶管理中？」或「有多少人更改了密碼？」
至於存儲空間的使用 - 我會說每個用戶的表可能會使用更多的空間，但兩個選項之間的差異應該很小。
我會去單桌。當您想要爲不同用戶組（多租戶）服務多個客戶時，您可能想要使用多個表。 否則，如果你去多個表，看看這個重構工具：http://www.liquibase.org/。您可以即時進行架構修改。
我想，如果你正在使用，即正確的索引，那麼單表解決方案可以執行得很好（並且維護將更加簡單）。
我們擁有超過1500萬條記錄的表格，並且仍然以毫秒爲單位搜索一個人。 – HLGEM
我從來沒有處理大小的表格的經驗 - 很高興知道搜索時間保持低點。 – Erik