前言：
1.對於mysql，不推薦使用子查詢和join是因為本身join的效率就是硬傷，一旦資料量很大效率就很難保證，強烈推薦分別根據索引單錶取資料，然後在程式裡面做join，merge資料。
2.子查詢就更別用了，效率太差，執行子查詢時，mysql需要建立臨時表，查詢完畢後再刪除這些臨時表，所以，子查詢的速度會受到一定的影響，這裡多了乙個建立和銷毀臨時表的過程。
3.如果是join的話，它是走巢狀查詢的。小表驅動大表，且通過索引字段進行關聯。如果表記錄比較少的話，還是ok的。大的話業務邏輯中可以控制處理。
4.資料庫是最底層的，瓶頸往往是資料庫。建議資料庫只是作為資料store的工具，而不要新增業務上去。
一、應用層關聯的優勢：
讓快取的效率更高。許多應用程式可以方便地快取單錶查詢對應的結果物件。如果關聯中的某個表發生了變化，那麼就無法使用查詢快取了，而拆分後，如果某個表很少改變，那麼基於該錶的查詢就可以重複利用查詢快取結果了。
將查詢分解後，執行單個查詢可以減少鎖的競爭。
在應用層做關聯，可以更容易對資料庫進行拆分，更容易做到高效能和可擴充套件。
查詢本身效率也可能會有所提公升。查詢id集的時候，使用in（）代替關聯查詢，可以讓mysql按照id順序進行查詢，這可能比隨機的關聯要更高效。
可以減少冗餘記錄的查詢。在應用層做關聯查詢，意味著對於某條記錄應用只需要查詢一次，而在資料庫中做關聯查詢，則可能需要重複地訪問一部分資料。從這點看，這樣的重構還可能會減少網路和記憶體的消豔。
更進一步，這樣做相當於在應用中實現了雜湊關聯，而不是使用mysql的巢狀迴圈關聯。某些場景雜湊關聯的效率要高很多。
二、應用層關聯的使用場景：
當應用能夠方便地快取單個查詢的結果的時候
當可以將資料分布到不同的mysql伺服器上的時候
當能夠使用in（）的方式代替關聯查詢的時候
併發場景多，db查詢頻繁，需要分庫分表
1.db承擔的業務壓力大，能減少負擔就減少。當表處於百萬級別後，join導致效能下降；
2.分布式的分庫分表。這種時候是不建議跨庫join的。目前mysql的分布式中介軟體，跨庫join表現不良。
3.修改表的schema，單錶查詢的修改比較容易，join寫的sql語句要修改，不容易發現，成本比較大，當系統比較大時，不好維護。
四、不使用join的解決方法：
在業務層，單錶查詢出資料後，作為條件給下乙個單錶查詢。也就是子查詢。 會擔心子查詢出來的結果集太多。mysql對in的數量沒有限制，但是mysql限制整條sql語句的大小。通過調整引數max_allowed_packet ，可以修改一條sql的最大值。建議在業務上做好處理，限制一次查詢出來的結果集是能接受的。
五、再來說說join查詢的好處：
1.做分頁查詢：
為什麼MySQL不推薦使用子查詢和join
前言 1.對於mysql，不推薦使用子查詢和join是因為本身join的效率就是硬傷，一旦資料量很大效率就很難保證，強烈推薦分別根據索引單錶取資料，然後在程式裡面做join，merge資料。2.子查詢就更別用了，效率太差，執行子查詢時，mysql需要建立臨時表，查詢完畢後再刪除這些臨時表，所以，子查...
mysql為什麼不推薦使用uuid作為主鍵
前言 在mysql中設計表的時候,mysql官方推薦不要使用uuid或者不連續不重複的雪花id long形且唯一 而是推薦連續自增的主鍵id,官方的推薦是auto increment,那麼為什麼不建議採用uuid,使用uuid究竟有什麼壞處？本篇部落格我們就來分析這個問題,一下內部的原因。1.1 要...
為什麼不推薦使用外來鍵？
外來鍵的優點 一 資料一致性 由資料庫自身保證資料一致性 完整性會更可靠，程式很難100 保證資料的一致性 完整性 二 er圖可靠性 有主外來鍵的資料庫設計可以增加er圖的可讀性 外來鍵的缺點 一 級聯問題 阿里巴巴的開發手冊中，就曾指出強制要求不允許使用外來鍵，一切外來鍵概念必須在應用層解決。因為...