請大神來講講資料庫資料量大的時候避免用join查詢的方式來做資料庫查詢最佳化

boss說平時查詢資料量大的資料盡量避免用join 寧可一次將一張表的資料查出來再用這些資料去做查詢 也不要用過多的使用join 盡量分成多次查詢來做 ，請大神來講講這其中的sql最佳化

回複內容：

boss說平時查詢資料量大的資料盡量避免用join 寧可一次將一張表的資料查出來再用這些資料去做查詢 也不要用過多的使用join 盡量分成多次查詢來做 ，請大神來講講這其中的sql最佳化

如果用了關係型資料庫，用表的join是很自然的做法，除非一些特例：

1. sql語句太複雜，或統計資訊不準確，造成資料庫產生的執行計畫不正確，導致運行效率低下，且短時間沒辦法改寫sql

2. 資料量特別大（至少過億），資料庫負載成為整個系統的效能瓶頸，在架構設計的時候就規定了不用資料庫本身的表串連功能。

3. 使用了ORM架構，對於關聯對象預設會使用N+1查詢的方式，如果資料量不是特別大，加上有緩衝功能，效率並不低。

所以一般情況下，用資料庫的join功能，比自己多次取資料做關聯效率要高，否則一張大資料量表，但是傳遞到PHP中，就要花費很長的時間。

sql最佳化最基本的原則，就是讓資料庫儘早、高效率的過濾資料，避免無效的運算，具體的手段比較多，需要根據不同的資料庫來確定實現方案。

請自行explain之。

這要看你資料庫連結是不是長連結了，如果配置為長連結的話還好一點，不過要join的時候可以首先通過where或者其他方法縮減你的主表，不要一股腦的拉起來，這樣的話效能會好很多。但是還是具體問題具體分析吧，跑一遍就有結果了哇。不過如果不是長連結的話估計連表會快一點。

分成多次查詢的原因是因為：無論是join還是子查詢，mysql最佳化器都會對sql進行最佳化（子查詢就會自作聰明辦壞事，join偶爾也會）
所以一條一條寫，自己可以把握

join方式其實挺好，主要是索引把握起來不是那麼的得心應手，容易出現問題。

所以你們boss直接說join不要用於大資料。

而分別查的原因：比如我拿到對應這邊的主鍵id，再到另外表去查，效率肯定是高得不要不要的。

一句話：越簡單的查詢效率越高

真不明白資料量大的情況下join了會導致效能低下，如果資料量大了單獨查詢某個表就幾百兆上G，載入到程式就花費好長時間

1. 索引會加快查詢速度

2. 利用緩衝（memchache等）

