Django ORM 如何实现 bulk_update_or_create

• 資深大佬 : hmxxmh

  for 循环 + update_or_create

• 主 資深大佬 : wonder1z

  @hmxxmh 数据量大的话 效率太低了

• 資深大佬 : est

  ORM 再厉害也没法实现 sql 支持不了的事。建议直接撸 insert … on duplicate update …

• 主 資深大佬 : wonder1z

  @est ORM 支持 update_or_create 的 只不过没有批量的 bulk_update_or_create。单条撸性能太差了

• 資深大佬 : hmxxmh

  @est 同意，orm 就是对 sql 的一层封装，真要追求效率直接撸 sql 比较好

• 資深大佬 : hmxxmh

  @wonder1z 平时只用 bulk_create,刚才查了一圈，没有看到 bulk_update_or_create。。。数据量有多大？

• 資深大佬 : Ehco1996

  @wonder1z

  bulk_create 的本质其实是 insert many

  而你的需求是 update_or_create 貌似单条 sql 是做不到的 ( 我也不确定

  我觉得比较简单的是分成两步 然后外面套事务
  * bulk_create
  * bulk_update

• 主 資深大佬 : wonder1z

  @hmxxmh 上千条
• 資深大佬 : ytymf

  @wonder1z 貌似只能循环了，with transaction.atomic 包裹一下，性能还有问题么

• 主 資深大佬 : wonder1z

  @ytymf 回头我试试

• 主 資深大佬 : wonder1z

  @Ehco1996 这样更复杂了吧

• 資深大佬 : hmxxmh

  @ytymf with transaction.atomic 只是进入事务，异常统一回滚，不能提升性能，其实我觉得一下创建上千条，肯定慢，放到 celery 里面让他慢慢跑吧

• 資深大佬 : ytymf

  @hmxxmh 你说的没错，这个原意只是保证原子性的事务提交。但在 django 实践中，确实比循环中的每次隐式事务提交快非常多，试试就知道了。

• 資深大佬 : ytymf

  @hmxxmh 具体的原因，猜测是是 model.save 应该会每次建立断开数据库连接，显式事务中 commit 后才断开。没有具体求证过

• 資深大佬 : hmxxmh

  @ytymf 这倒是没注意过

• 資深大佬 : encro

  @hmxxmh
  @ytymf
  Mysql 中一次插入大量数据，采用事务能明显提升性能，这个是事实，
  和 model 没有关系，直接用 sql 也是一样性能差距明显，（一次几十万条数据就能测试出来，我们有时候做性能测试需要一次生成大量数据都是采用事务或者 prepare，原来干几十分钟的，几分钟就行了）
  猜测应该日志配置，索引，寻址有关，
  比如每条记录写一次日志然后确认，与一次性写入一批日志，然后确认。