認真來說，這些都是資料庫優化的方式。
正常來說，早期來說，確實IO是首當其衝的問題之一。
但就現階段的硬體來看。使用SSD的話。
IO的讀寫問題就顯得不那麼明顯重要了。
漸漸的，開始有了新的做法及看法了。

JOIN的用法，其實現在新的做法，如ORM的應用。
就是已經走向不用JOIN的方式
其也突顯了JOIN的使用之效能優化的必要性。

但曾經也有人跟我說。那我不分表全部放在同一張表的情況下。是不是比較好?
這就不一定了。
一張表太大，也會去影響到RAM的使用率。
而大多數分表來說，其最大的目的是依需求而取用的目的。大大的降低讀取及使用的容量。

結論：
並不是說，JOIN用多不好，還是IO問題就盡量少讀。
這些並沒有一定的絕對性。
畢竟，量大量小或是分區分配的情況不同。 有適合用子查尋、也有適合用JOIN。
也有適合多並發請求。
這些並沒有一定絕對性說哪種方法比較好及比較不好。
只有適合及不適合你當下的應用架構及寫法。

個人認為資料庫瓶頸在於大table的join，也在I/O，視使用情境的不同。
例如，兩個幾百萬筆的大table要join, 比對勢必對資料庫產生極大的負擔，解決辦法很多：

1. 各自撈下來，由Client端PC處理，可幫Server減壓。
2. 反正規化，把常用的join放在同一個表。
3. 使用 stored procedure。
4. 使用 NoSQL 資料庫或Time Series Database。
5. Partition、Sharding等分散式處理。

相對的，若網站使用者很多，頻繁查詢資料庫，自然造成I/O瓶頸，，解決辦法也很多：

1. 使用資料庫的Cache。
2. 將常查詢的資料，例如最新股價，拉出來成為單獨的資料表。
3. 使用 Redis 或 Memory Database。

用實際的狀況跑分析最準，不同的狀況，發生的瓶頸也以可能會改變