可以說我有用戶表：
| id |用戶名|電子郵件|地址|
避免JOIN提高性能？
而且帖子表：
| id |後| | user_id |日期|
當我想顯示帖子時，每次我需要去用戶表來從user_id檢索用戶名。我想避免使用JOIN進行簡單數據檢索，因此我所做的是在帖子表中添加另一個顏色：
| id |後| | user_id |用戶名|日期|
這樣我就不必使用JOIN中檢索用戶名會顯示在帖子
你認爲這是更好？
沒有。您的替代結構很容易出現不一致（例如，如果用戶更改了他的名字;請閱讀第三種標準表格http://en.wikipedia.org/wiki/Third_normal_form#.22Nothing_but_the_key.22） 爲什麼不想使用JOIN？你有沒有設置適當的索引？
我認爲這取決於設計和未來，NIY我會建議你不要做：
雖然從目前的尊重，你會認爲這將是更好的性能，以避免加入，但如果你的應用擴展一下，並且使用這種非標準化的表結構並不好。
例如，如果其中一個海報更改了用戶名，那麼您如何實現這一點？更新整個表格？如果您的數據可能會超過1000萬個元組，那麼將會很困難，因爲update會在更新過程中鎖定表。
因此我不會推薦這個。
如果您的應用程序需要頻繁更新，那麼可以忽略聯接性能。
是的計劃是更新表。不過，我同意你，它需要更新大型表，我的妥協是假設這不會經常發生（不像每個職位retreiving用戶名） – DeepBlue
如果[users]表中的[id]是主鍵，我認爲使用JOIN已經足夠好了。
另外，如果你選擇的posts數量有限，如10個職位，也可以嘗試這個SQL：
select id, post, user_id,
(select username from users where id = user_id) as username, date
from posts
limit 0, 10
沒有理由，以避免簡單的內部連接。如果你在'user_id'上放置一個外鍵索引，那麼連接就不會有明顯的性能影響。 Mysql是爲這種事情而構建的。 – miyasudokoro
多個（3-4）連接的表現如何？ – DeepBlue
如果它們都是索引連接，那麼不會，幾乎沒有性能影響。 – miyasudokoro