我創建了一個網站，我需要有一個用戶的活動（類似於您在計算器收件箱）存儲在SQL的過程。目前，我和我的隊友正在爭論最有效的方法來做到這一點;到目前爲止，我們已經提出了兩種備選方法來執行此操作：SQL中哪個更快：很多很多表與一個巨大的表？
"...WHERE username=".$loggedInUser
任何替代的方法也將被理解的
1號簡直是完全瘋了。你能想象去管理它，並看到所有這些表格。
你能想象備份！或者轉儲！那麼多人創建桌子......那會很瘋狂。
給你一個好的索引，你將不會有任何問題通過記錄排序。
「的Cre爲每個用戶吃了一張新桌子...最後，我將得到一張TON表格「
這從來不是使用關係數據庫的好方法。
SQL數據庫可以與數百萬行（及以上）的應付得很好，即使是在商品硬件。正如您已經提到的那樣，您顯然需要可用的索引來涵蓋將在此表上執行的所有可能的查詢。
在某些情況下，第一種選擇是，儘管不是嚴格的「關係方式」，略微更好，因爲它使您在增長時將數據庫分散到多個服務器更簡單。 （這樣做正是允許wordpress.com擴展到數百萬個博客的原因。）
關鍵是隻有在完全獨立於用戶的表格的情況下才能做到這一點 - 即從不查詢。
在你的情況，選擇2使得大部分情況下：你幾乎可以肯定將要查詢的所有活動或在某些時候一些用戶。
不是wordpress數據庫每個博客，而不是每個用戶的表？ –
每個服務器一個數據庫，每個博客一個前綴。前綴看起來像'wp_1_'，'wp_2_'等等，通往'wp_1_posts'，'wp_2_posts'等，但只有一個'wp_users'（在主/網絡服務器上）。 –
對，但是不是作者詢問每個用戶創建一個表嗎？想象一下，每次用戶註冊時，都會創建一個wordpress博客，創建一個新表來跟蹤他們的活動。 –
這majorly現在取決於你在哪裏需要檢索的值。如果其爲單個用戶的頁面，則使用第一種方法。如果您顯示所有用戶的數據，則應使用單個表。使用多個表的方法也乾淨，但在SQL如果在一個表中的記錄數都非常高，數據檢索速度很慢
你想要第二個選項，並添加userId（並可能爲用戶名，用戶名等分開的表）。
如果您在正確編入索引的字段上對該ID進行查找，則只需要諸如log(n)步驟來查找您的行。這根本就不是什麼東西。它會更快，更清晰，方式更好，然後選擇1.選項1是愚蠢的。
使用選項2，不僅索引該列的用戶名列，還索引分區（考慮散列分區）。對用戶名進行分區將爲您提供與第一個選項相同的好處，並讓您保持理智。以這種方式對列進行分區和索引將提供基於username/user_key訪問數據的非常快速有效的方法。查詢分區表時，SQL引擎可以立即關閉不需要掃描的分區，因爲它可以根據查詢的用戶名值與該用戶名駐留在分區內的能力來判斷。 （在這種情況下，只有一個分區可能包含與該用戶綁定的記錄）。如果將來需要在多臺服務器上分割表，則分區不會妨礙該功能。
您還需要通過用user_key將用戶名字段（以及與用戶名相關的表中的其他元素）分隔到其自己的表中來對錶進行規範化。確保用戶名錶中user_key字段的主鍵。
這裏我們來談談MySQL。那麼，爲什麼分開表格會更快？
但是正如所有人在這裏所說的那樣，在管理方面是非常瘋狂的。但是就表現而言，擁有大量表格會在mySQL中增加另一個問題，您可能會運行我們的文件描述符或者只是簡單地擦除表格緩存的。
在這裏可能更重要的是選擇正確的引擎，如MyIsam而不是Innodb，因爲這是一個只插入表格。並且@RC表示好的分區策略將通過避免在活動內存緩衝區中很少使用的數據的加載來修復內存分頁問題。這也應該通過智能應用程序設計來完成，在這種情況下，您可以避免默認加載所有活動歷史記錄，如果將其降至最近的活動並將完整的歷史記錄表分析爲批處理過程和高級屏幕，您將獲得分區效果很好。您甚至可以嘗試基於用戶的分區策略。
對於查詢緩存效率，您可以通過使用應用程序級別緩存（如memcache）以及每個用戶保存的歷史記錄元素以及每次新插入時清空它來獲得更大的增益。
你會瘋狂嘗試和實施（1）。 –
這就是我原先想的，我的隊友提出了一個令人信服的觀點，即2會令人難以置信地變得更慢，只要我們的用戶羣沒有進入成千上萬的應用，就不會有太多問題 – Tomas
@Damien：它禮貌地。數據庫*內置*有一排行，爲什麼你想拍攝自己的腳？你打算如何加入這個怪物？ @Tomas：「令人難以置信的慢」？你們哪裏得到統計數據？ 「輸入數千」？數以千計的數據庫是沒有什麼的。你意識到它會花費你*也許* 2毫秒來查詢一個具有數十或數十萬行的表，如果它正確索引？ – mpen