EF框架从五百万条数据中查询数据的性能提升

文章背景：需要从一个拥有五百万条以上数据的表中查询数据，使接口响应耗时不超过300ms。

缓存是一个没有明确定义的技术，一个static变量是一个缓存，一个static集合就是一个缓存容器。 这种缓存与ASP.NET Cache相比起来，显然static变量的访问速度会更快， 并发的冲突也可能会比ASP.NETCache小，也正是因为这一点，static集合也有着广泛的使用。 然而，ASP.NET Cache的一些高级功能，如：过期时间，缓存依赖（包含文件依赖），移除通知，也是static集合不具备的。因此，合理地同时使用它们，会让程序有着最好的性能，也同时拥有更强大的功能。

最开始的三种方式

1. 将数据列表存储为static变量

2. 将数据列表放入ASP.NET应用程序的Cache（HttpRuntime.Cache）
   了解HttpRuntime.Cache相关信息，请进入传送门。

3. 将数据列表放入Redis以上3种方式的实质是遍历一个存储了五百万条数据的List变量（大对象），从中查询出符合条件的数据，对性能提升并没有帮助，在数据量较少时，没有丝毫问题，但数据量过大后会成为大对象，导致IIS内存溢出。

启发

为什么直接写SQL比我从缓存里的列表读取还要快？
答：查询缓存列表时遍历了整个列表，而使用SQL查询数据库可避免全表扫描。

过度依赖LINQ，忽略了原生SQL语句

//查询示例(遍历了整张表，性能较差)
using (var context = new DbContext())
{
    var dataList = context.table.ToList();
}

性能优化方法

1. 非跟踪查询
2. 原始SQL查询
3. 参考《C#中EF(EntityFramework)性能优化》

总结

认为内存读取速度比数据库快，且该部分数据只读不写，就把数据一股脑全部缓存，每次读取都需要全部遍历一遍，反而把效率降低了。最终我放弃缓存，选择使用EF进行原始SQL查询，在没有加索引的情况下，把接口响应速度降低到100ms以下