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

解決方法： 加fetch
示例：

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

注意點：
1、第一個left join fetch后面必須跟b.account而不是Account實體！
2、第二個left join fetch后面必須跟a.userInfo而不是UserInfo實體也不是b.account.userInfo這種方式！
3、通過這種方式會無視fecth類型，避免出現多條sql，避免N-1問題
4、這種方式同樣適用與N-1或者1-1，因為默認查詢會出現兩條sql，這種方式自始至終只會是一條sql！


完！