id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	due_date
117	商城6.1版上线时发生的灵异事件	huangzhong		"* 现象
应用上线后，功能检查一切正常，突然1点数据库负载变高，去到了4左右，让dba抓了下慢语句，发现大量类似如下的SQL语句
{{{

SELECT t0.IMG1, t0.IMG2, t0.IMG3, t1.id, t1.BIG_PIC_PATH,
 
t1.BRAND_NAME, t1.LAST_COUNT_ORDER, t1.CREATE_DATE, t1.FORUM_PATH, 

t1.HOT_NEW, t1.MID_PATH, t1.name, t1.ORDER_KEY, t1.price, 

t1.PRICE_CONFIG, t1.PUB_URL, t1.REVIEW_STATUS, t1.SHORT_NAME, 

t1.PIC_PATH, t1.SMALLTYPE_ID, t1.TYPE_ID, t1.VARIANCE_ID FROM 

ENT_PRODUCT t0 LEFT OUTER JOIN V_PDL_PRODUCT t1 ON t0.PRODUCT_ID = 

t1.id WHERE t0.id = $1

}}}

* 检查
找遍了整个应用，都没有找到这个SQL语句的出处，IMG1, IMG2, IMG3是本次上线中商品表(ent_product)的新增字段，存放商品的图片信息，起初怀疑是商品详情页出现的问题，因为只有这个页面才会用到这几个字段，让网络对外封闭了239.45服务器，然后让dba只抓取通过239.45过来的慢语句，直接访问239.45的商品详情页，但没出现这些SQL。各种找，各种忙，都没有头绪，后来在崇锜的帮组下通过threads.jsp定位到了两个很值得怀疑的jsp，这个两个jsp都是提供给其他应用调用的接口，崇锜在本地环境打开jpa的日志，打印出jpa的sql语句，发现访问这两个接口确实会出现上述的SQL语句。

* 原因
这里提下商城的背景，比较容易理解。
ent_product表：商城的商品表(有效和无效的商品都有)，对应CompanyProduct类
v_ent_product视图：商城的有效商品视图(为了提高性能，数据量是ent_product的1/3)
v_ent_product1表：v_ent_product的基表，由定时任务填充数据并切换
v_ent_product2表：v_ent_product的基表，由定时任务填充数据并切换
v_pdl_product视图：产品视图

经常在接口中查询v_ent_product，然后组装成CompanyProduct对象，这时问题就出现了。前面提到过ent_product表有变更，新增了三个字段，但是v_ent_product里没有新增，这个视图对应的v_ent_product1和v_ent_product2表中也没有新增这三个字段，从v_ent_product中获得数据并组装成CompanyProduct对象的时候，jpa不会报错，反而自动做些事情，它发现结果集中缺少IMG1、IMG2、IMG3这三个属性，就自动从ent_product中拿这三个属性补全

* 解决方案
把v_ent_product1、v_ent_product2和v_ent_product都加上这三个字段。

----
补充一下，如果表里有img1、img2、img3的数据的话，我估计他只会组装这样的sql拿一次，而不是像上线这种情况反复拿，大家可以自行验证一下。"	defect	new	major		商家后台	6.1				18/10/2012