JPA 底层的智能化技术
上线过程很顺利，在上线完成后，发现数据库又大量的，慢sql。
都是根据一个id去做两个表的 left join
于是翻天覆地的去找个sql 来自于那个业务模块。 结果翻了一个地朝天也没有找到。
奇怪了， 先上的监控，并发有每秒几十个这种sql，肯定是一个经常被访问的地方，没有道理。
最后经过监控java 线程的动作。找到了问题所在。
引出了一段曲折的故事：
假如 有两个表 product 与product-item 表。对应于head detail 的关系。
在接口实现过程中，一般会用 手工的sql 直接去查询 product-item 表，然后把生成的结果集，转化/封装为一个product 对象返回给调用者。
这个实现也是没有问题的。
关键是JPA 的底层实现太智能化了，有点过头了， 底层发现你封装的这个product 实例中，有一部分字段是空的，
于是JPA 的底层就在想了，你丫的，怎么能这么干呢，资料不全啊。影响严重啊， 于是底层的自动补全机制，开始运作了，把你封装出来的结果集遍历一遍，对立面的每个对象都去 product 表里把相应的缺失的字段查出来，然后合并到你的结果集中。
问题关键是你的本意是，这些缺失的字段在真正的业务逻辑中是用不到的，不然谁傻傻的做这破事？
如果恰巧，你自己封装的结果集中，没有key。 那么对不起了。 开始的那个问题就出来。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/133735/viewspace-746702/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
lisp 开发规范。
下一篇：
疑难文件的删除方案
请登录后发表评论
登录
全部评论
