我必须更新我的Doctrine实体以匹配(可能很大)XML文件中的记录。我还必须根据XML中的数据更新ManyToMany关联。这是我在循环内执行的操作:
ArrayCollection
ArrayCollection::clear()
ArrayCollection::add()
*循环 *后 ,我打电话EntityManager::flush()。
EntityManager::flush()
问题在于,刷新会产生大量查询,而不是立即更新/插入/删除多行。对于每个实体,执行以下查询:
所以总共以XML记录了305条记录,我得到915个查询(如果所有实体都会更改,我想最多可以查询1220个查询),这使导入非常缓慢。
我可以在循环之前利用IdentityMap和预取实体,但是仍然有UPDATE / DELETE / INSERT查询。
您做对了-这只是很慢,因为添加的ORM抽象意味着您无法进行所需的优化。
就是说,EntityManager在这么大的事务上确实变慢。如果您绝对不需要在一个大事务中全部使用它们,则可以通过flush()ing然后每20-200次循环clear()清除EM来获得性能更高的代码。
如果那不能给您足够的性能,我能想到的唯一替代方法是还原为直接对DBMS运行自定义SQL的自定义代码。
我知道这不是一个很好的答案,但是至少我可以告诉你,你并不疯狂。
------编辑------
摘自Doctrine2有关批处理的官方文章:
某些人似乎想知道为什么Doctrine不使用多重插入(将插入到(…)值(…),(…),(…),… 首先,此语法仅在mysql和较新的postgresql版本上受支持。其次,当使用AUTO_INCREMENT或SERIAL且ORM需要使用这些标识符进行对象的身份管理时,没有一种简单的方法可以在这种多插入中获取所有生成的标识符。最后,插入性能很少是ORM的瓶颈。普通插入在大多数情况下已经足够快,如果您真的想进行快速批量插入,那么无论如何多插入都不是最好的方法,即Postgres COPY或Mysql LOAD DATA INFILE快几个数量级。 这就是为什么不值得在ORM中实现在mysql和postgresql上执行多插入的抽象的原因。
某些人似乎想知道为什么Doctrine不使用多重插入(将插入到(…)值(…),(…),(…),…
首先,此语法仅在mysql和较新的postgresql版本上受支持。其次,当使用AUTO_INCREMENT或SERIAL且ORM需要使用这些标识符进行对象的身份管理时,没有一种简单的方法可以在这种多插入中获取所有生成的标识符。最后,插入性能很少是ORM的瓶颈。普通插入在大多数情况下已经足够快,如果您真的想进行快速批量插入,那么无论如何多插入都不是最好的方法,即Postgres COPY或Mysql LOAD DATA INFILE快几个数量级。
这就是为什么不值得在ORM中实现在mysql和postgresql上执行多插入的抽象的原因。
当使用 远程 数据库 与本地 数据库时,由于将每个查询发送到远程服务器的开销也很大,因此性能上也存在显着差异。借助事务和数据库优化,使用本地数据库时的开销要低得多。(例如,在问题示例中,70秒降低到300ms)