实体框架如何适用于大量记录？ [英] How entity framework works for large number of records?
问题描述
我已经看到一个未回答的问题此处。
I see already a un-answered question here on.
我的问题是 -
对于大型应用程序？
Is EF really production ready for large application?
这些问题源于这些基本问题 -
The question originated from these underlying questions -
- EF将所有记录拉入内存，然后执行查询
操作。当表格有大约1000个记录时，EF的行为会如何？ - 对于简单的编辑，我必须将记录编辑到
，然后使用SaveChanges（）
- EF pulls all the records into memory then performs the query operation. How EF would behave when table has around ~1000 records?
- For simple edit I have to pull the record edit it and
then push to db using
SaveChanges()
推荐答案
有一个大型数据库，许多表格每个都有1000万条记录。我们使用Entity框架来显示数据。要得到好的表现，这里是我学到的; 我的10个实体框架的黄金规则：
I faced a similar situation where we had a large database with many tables 7- 10 million records each. we used Entity framework to display the data. To get nice performance here's what I learned; My 10 Golden rules for Entity Framework:
-
了解到只有当实际需要记录。所有的操作只是用来使查询（SQL），所以尝试只获取一块数据，而不是请求大量的记录。修改抓取大小尽可能
Understand that call to database made only when the actual records are required. all the operations are just used to make the query (SQL) so try to fetch only a piece of data rather then requesting a large number of records. Trim the fetch size as much as possible
是的（在某些情况下，存储过程是一个更好的选择，它们不是那么邪恶，有些让你相信） ，您应该在必要时使用存储过程。将它们导入到您的模型中并为其输入功能。您也可以直接调用它们ExecuteStoreCommand（），ExecuteStoreQuery<（（））。功能和视图也是一样的，但EF有一个非常奇怪的方式调用函数SELECT dbo.blah（@id）。
Yes, (In some cases stored procedures are a better choice, they are not that evil as some make you believe), you should use stored procedures where necessary. Import them into your model and have function imports for them. You can also call them directly ExecuteStoreCommand(), ExecuteStoreQuery<>(). Same goes for functions and views but EF has a really odd way of calling functions "SELECT dbo.blah(@id)".
必须填充深层次的实体。对于具有深层次的实体，请非常小心
EF performs slower when it has to populate an Entity with deep hierarchy. be extremely careful with entities with deep hierarchy
有时，当您要求记录，您不需要修改它们时，您应该告诉EF不要看到属性更改（AutoDetectChanges）。这种记录检索速度要快得多。
Sometimes when you are requesting records and you are not required to modify them you should tell EF not to watch the property changes (AutoDetectChanges). that way record retrieval is much faster
数据库的索引很好，但是在EF的情况下变得非常重要。您用于检索和排序的列应该被正确索引。
Indexing of database is good but in case of EF it becomes very important. The columns you use for retrieval and sorting should be properly indexed.
当您的型号很大时，VS2010 / VS2012型号设计师变得真实疯狂。所以将你的模型打破中型模型。有一个限制，不同模型的实体不能共享，即使它们可能指向数据库中的同一个表。
When you model is large, VS2010/VS2012 Model designer gets real crazy. so break your model into medium sized models. There is a limitation that the Entities from different models cannot be shared even though they may be pointing to the same table in the database.
当你必须做在同一个实体在不同的地方进行变更，使用相同的实体，进行更改并保存一次。关键是AVOID检索相同的记录，进行更改&保存多次。 （实际表现增益提示）。
When you have to make changes in the same entity at different places, use the same entity, make changes and save it only once. The point is to AVOID retrieving the same record, make changes & save it multiple times. (Real performance gain tip).
当您只需要一列或两列时，请尽量不要获取完整的实体。你可以直接执行你的sql或一个迷你实体。您可能需要在您的应用程序中缓存一些常用的数据。
When you need the info in only one or two columns try not to fetch the full entity. you can either execute your sql directly or have a mini entity something. You may need to cache some frequently used data in your application also.
交易缓慢。小心他们。
SQL Profiler或任何查询分析器是您的朋友。在开发应用程序时运行它，以查看EF发送到数据库的内容。当您在ur应用程序中使用LINQ或Lambda表达式执行连接时，EF通常会生成Select-Where-In-Select样式查询，可能并不总是很好。如果您发现任何这种情况，请卷起袖口，在DB上执行连接并获取EF检索结果。 （我忘了这一个，最重要的一个！）
SQL Profiler or any query profiler is your friend. Run it when developing your application to see what does EF sends to database. When you perform a join using LINQ or Lambda expression in ur application, EF usually generates a Select-Where-In-Select style query which may not always perform well. If u find any such case, roll up ur sleeves, perform the join on DB and have EF retrieve results. (I forgot this one, the most important one!)
如果你记住这些事情EF应该给几乎与普通ADO.NET相似的性能如果不一样。
if you keep these things in mind EF should give almost similar performance as plain ADO.NET if not the same.
这篇关于实体框架如何适用于大量记录？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
