事發(fā)經過：

之前用這個功能都是好好的，后來運營那邊反應，突然就不行了，然后我自己測試了一下，新增了瞎寫的卡號和卡密是正常的，運營那份表格批量導入就不行，我就向crmeb客服反饋，客服那邊用我的表格導入也是正常的，當時我就納悶了，因為自己也是開發(fā)，翻翻源碼結合線上調試，終于找到問題了。

我編輯的商品product_id是31，發(fā)現(xiàn)product_virtual里面product_id 19已經有了我31想導入的數(shù)據，于是我返回product表看，發(fā)現(xiàn)是product_id 19是已經刪除了，但是副表數(shù)據還存在，于是我把副表的數(shù)據刪除了，然后導入就成功了，為了看看具體的原因我看了一下源碼，代碼上看副表數(shù)據應該是有刪除的，但是執(zhí)行了一大托業(yè)務既然沒有做事務，我就知道大概得原因了，估計是網速卡頓或者高負載的情況下，由于沒有事務腳本執(zhí)行到一半就沒有執(zhí)行了，就會產生這樣的奇怪問題。

我全局搜索了一下用事務的地方 Db::startTrans() ，只有3個地方用了事物，分別是

1.auto_upgrade

2.upgrade

3.databaseUpgrade

我個人建議

1、大量的業(yè)務進行多表操作還是需要加上事務，不然出現(xiàn)網速慢、斷線、斷電、高負載等不可抗因素好難保持數(shù)據的一致性。

2、批量寫入數(shù)據不要在循環(huán)一條一條寫入，應該拼接成數(shù)組一次性寫入，如果導入的數(shù)據量大會耗沒數(shù)據庫鏈接的。

希望官方采納，謝謝?。。?/p>