一、起因
上次做的是EF百万级数据的单表查询，总结了一下，在200w以下的数据量的情况(Sql Server 2012)，EF是可以使用，但是由于查询条件过于简单，且是单表查询，EF只是负责生成Sql语句，对于一些简单的查询，生成Sql语句的时间可以基本忽略，所以不仅没有发挥出EF的优势，而且这样的性能瓶颈基本可以说是和数据库完全有关的，这个锅数据库得背(数据库：怪我了)。鉴于实际项目中多是多表的连接查询，还有其他复杂的查询，一向本着求真务实的思想的博主就趁此机会再次测试了一下EF的复杂的连接查询什么的。说实话，在测试之前我也不知道结果，只是为了自己以后用起来有个参考依据，也比总是听别人说EF性能很差，吓得都不敢用了要好。EF的性能到底有多差，或者说可以胜任什么样的场景，不吹不黑，我们就一起来看看，也好在以后的实际项目选型的时候参考一下。
二、关于很多ORM框架的对比测试
博主最近也看了不少关于ORM框架的测试，大多数都是增删改几千，几万条的数据，这样确实可以看出来性能的比较，但是实际项目中真的很少有这样的情况，一次增删改几千几万条数据的，我们做项目服务的都是用户，按用户的一次请求为一次数据库上下文的操作，同一个上下文在这样的一次请求中基本不可能同时提交这么多的数据操作，有人说那要是成千上万的用户同时呢，那就要考虑并发了，就不是本文所要讨论的问题了。所以这些测试能表明结果，但是不能表明实际问题。另外在大多数对于EF的测试中，很多人忽略了EF对于实体的跟踪，比如：
这些属性虽然我不全知道是什么的东西，但是既然可以设置Enabled，就说明是对性能有影响的，而且数据量越多，相信影响也越大，但其他多数ORM
