問題：
1、一般情況下，配置好映射@OneToOne @OneToMany @ManyToMany。
2、在配置下fetch類型，Lazy或者Eager。
3、然后from one 或者from many時(shí)候的就能正常查詢。
但是以上查詢，
    1:在N-1或者1-1的時(shí)候，會(huì)出現(xiàn)兩條查詢sql(不管是Lazy還是Eager，只要使用one方)
       對(duì)于N-1，先查詢Many方實(shí)體，其次再查詢one方的實(shí)體；
       對(duì)于1-1，先查詢當(dāng)前one實(shí)體，其次再查詢關(guān)聯(lián)方one實(shí)體；
       這兩種方式性能都可以忽略不計(jì)，因?yàn)椴还茉趺礃覮azy也好，Eager也好，都是兩條sql， 其實(shí)一條sql也可以解決，下面再說，可以忽略不計(jì)
    2:在1-N或者N-N的時(shí)候，會(huì)出現(xiàn)性能問題， 不管是Lazy還是Eager
       對(duì)于1-N，先查詢one方實(shí)體，其次再查詢many方實(shí)體，也是兩條sql（只要使用many方），
       如果是Lazy，那么只查詢one方實(shí)體，內(nèi)存中只加載one方，而不會(huì)加載many，只在需要的時(shí)候加載，內(nèi)存占用小；
       如果是Eager，那么不僅加載one方，仍然要加載many方，內(nèi)存占用會(huì)大，且立刻執(zhí)行兩條sql；
       如果一條sql根據(jù)條件查詢出來的one方有100個(gè)，那么也就意味著many方也需要查詢100次，因?yàn)槭?00個(gè)(1-N)，這會(huì)影響效率，應(yīng)該是一條sql搞定！
       為什么N-1或者1-1不會(huì)出現(xiàn)這種問題？ 因?yàn)橛疫叾际?啊，只查一個(gè)啊，左邊再多，右邊都只有一個(gè)
       對(duì)于N-N，其實(shí)就是兩個(gè)1-N，跟上面效果一樣。

解決方法： 加fetch
示例：

關(guān)系：Booking關(guān)聯(lián)Account(ManyToOne)，Account關(guān)聯(lián)UserInfo(OneToOne)
結(jié)果：這個(gè)查詢的結(jié)果是，不管滿足條件的Booking有多個(gè)還是一個(gè)，但是同時(shí)立刻抓取出與之相關(guān)的account實(shí)體值以及account實(shí)體關(guān)聯(lián)的userInfo值
        適用于任意關(guān)系（1-N/N-1/1-1/N-N）

注意點(diǎn)：
1、第一個(gè)left join fetch后面必須跟b.account而不是Account實(shí)體！
2、第二個(gè)left join fetch后面必須跟a.userInfo而不是UserInfo實(shí)體也不是b.account.userInfo這種方式！
3、通過這種方式會(huì)無視fecth類型，避免出現(xiàn)多條sql，避免N-1問題
4、這種方式同樣適用與N-1或者1-1，因?yàn)槟J(rèn)查詢會(huì)出現(xiàn)兩條sql，這種方式自始至終只會(huì)是一條sql！


完！