上线过程很顺利，在上线完成后，发现数据库又大量的，慢sql。

都是根据一个id去做两个表的  left join


于是翻天覆地的去找个sql 来自于那个业务模块。 结果翻了一个地朝天也没有找到。

奇怪了， 先上的监控，并发有每秒几十个这种sql，肯定是一个经常被访问的地方，没有道理。

最后经过监控java 线程的动作。找到了问题所在。

引出了一段曲折的故事：

假如 有两个表   product   与product-item 表。对应于head detail 的关系。

在接口实现过程中，一般会用 手工的sql  直接去查询 product-item 表，然后把生成的结果集，转化/封装为一个product 对象返回给调用者。

这个实现也是没有问题的。
关键是JPA 的底层实现太智能化了，有点过头了， 底层发现你封装的这个product 实例中，有一部分字段是空的，

于是JPA 的底层就在想了，你丫的，怎么能这么干呢，资料不全啊。影响严重啊， 于是底层的自动补全机制，开始运作了，把你封装出来的结果集遍历一遍，对立面的每个对象都去 product 表里把相应的缺失的字段查出来，然后合并到你的结果集中。


问题关键是你的本意是，这些缺失的字段在真正的业务逻辑中是用不到的，不然谁傻傻的做这破事？

如果恰巧，你自己封装的结果集中，没有key。 那么对不起了。 开始的那个问题就出来。