JPA 底層的智慧化技術

上線過程很順利，在上線完成後，發現資料庫又大量的，慢sql。

都是根據一個id去做兩個表的  left join


於是翻天覆地的去找個sql 來自於那個業務模組。 結果翻了一個地朝天也沒有找到。

奇怪了， 先上的監控，併發有每秒幾十個這種sql，肯定是一個經常被訪問的地方，沒有道理。

最後經過監控java 執行緒的動作。找到了問題所在。

引出了一段曲折的故事：

假如 有兩個表   product   與product-item 表。對應於head detail 的關係。

在介面實現過程中，一般會用 手工的sql  直接去查詢 product-item 表，然後把生成的結果集，轉化/封裝為一個product 物件返回給呼叫者。

這個實現也是沒有問題的。
關鍵是JPA 的底層實現太智慧化了，有點過頭了， 底層發現你封裝的這個product 例項中，有一部分欄位是空的，

於是JPA 的底層就在想了，你丫的，怎麼能這麼幹呢，資料不全啊。影響嚴重啊， 於是底層的自動補全機制，開始運作了，把你封裝出來的結果集遍歷一遍，對立面的每個物件都去 product 表裡把相應的缺失的欄位查出來，然後合併到你的結果集中。


問題關鍵是你的本意是，這些缺失的欄位在真正的業務邏輯中是用不到的，不然誰傻傻的做這破事？

如果恰巧，你自己封裝的結果集中，沒有key。 那麼對不起了。 開始的那個問題就出來。