问题描述
我懒得测试了，想请大家帮忙测试下，并发下理性、有效的性能测试过程及结论。问题：从数据库里查询一个小型表（万级以下）或中型表(万级以上,百万以下)，全取出结果。再多的数据，就不符合场景了，不在这里讨论。把结果集存入缓存，这样之前开关SQL的IO的效率就可以忽略了，不在这讨论。下面对结构集做筛选操作的几种方法进行讨论研究。1、存入DataSet的DataTabledt中。用dt.select("col1like'%xxx%'")筛选结构。2、存入DataSet的DataTabledt中。用dt.DefaltView.Filter="col1like'%xxx%'";3、存入List<类mode>lst中。用lst.where(o=>o.col1.indexof(xxx)>=0).toList()4、linq或EF的相应操作，我相信更慢，（这个结论对吧？）有测试过程最好。比较上面4种方法哪种效果高？1、要结论2、有测试过程数据，更给分3、小型表和中型表结论是否一致？4、如果DataTable设了主键，会否提高筛选效率？
解决方案
解决方案二：
另外，还有啥更高效存结果集的方式（.Net环境内，程序中），也可以谈谈。nosql/或框架上的建议就不要过多讨论了。
解决方案三：
没有测试，根据多年的.Net开发经验：如果只进行一次查询，从空间利用和查询时间上，我倾向于第3种方法。如果要进行多次查询，从查询效率和架构设计上，我倾向于直接从数据库查询，利用查询字段的数据库索引。
解决方案四：
引用2楼fungchou的回复:
没有测试，根据多年的.Net开发经验：如果只进行一次查询，从空间利用和查询时间上，我倾向于第3种方法。如果要进行多次查询，从查询效率和架构设计上，我倾向于直接从数据库查询，利用查询字段的数据库索引。
肯定是要频繁遍历该表，又要like，用不了数据库的索引。又因为知道数据库io开销肯定比放缓存里，遍历结果集小。才提出这问题。关键是，1、2、3哪个更快？
解决方案五：
我只凭经验说一下。一首先1比2要快，dataView慢是出名的。二3和1比较的话，我个人偏向于3可能快。三你既然用了like并且%前置，那么索引就无效了
解决方案六：
Redis不能算？叫我弄的话，首先DataSet不会作为内存存储的方式，我还是会选择List<Entity>的方式，这样更能预先进行排序（其实你可以认为就是主键作用了），然后适用各种查找算法（甚或者直接Hash来做映射）其实上面都是扯淡，不同的查询条件，对应的插法不同，你硬要脱离数据库，其实也就是放弃了索引这个利器，而还想要效率的话，那也就是你自己要在程序里实现“索引”（算法），因为算法是可预料的，所以实际可能效率上还会高于“索引”至于测试、结论啥的，拜托，你好歹也是SQL版蓝花，没有任何约束限制条件的测试有何意义？
解决方案七：
Trie图
解决方案八：
楼主，就单次执行时间而言，你认为最慢的，恰恰是最快的。因为你把全部数据加载到datatable或list的时间就远超直接查询获得结果的时间。如果不算数据加载到内存的时间，第三种最快，因为list是强类型的，少了类型转换的时间
解决方案九：
肯定3最快而且肯定不应该是这样的o=>o.col1.indexof(xxx)>=0
解决方案十：
我只从你的帖子看到几点：1.你不知道像drt.select(...)、dataview.Filter=....这类字符串要付出代价去进行语法解释和临时编译，而产生的结果其实就模仿3、4。2.你不知道Linq其实为何物，你竟然不知道3中的where(....)就是linq，而4中的“linq或EF”也是linq。3.你不知道有索引和无索引的区别。你不懂“主键”跟你的那个查询表达式有没有什么关系？！4.你没有动手能力。连写个7、8代码的测试都动不动就说“我懒得测试了”。5.你比较喜爱发帖。贴别是拿不出自己的测试代码，但是忽悠别人的帖子。你可能是很适合博客园的那种发文章的风格。
解决方案十一：
我还是强调一次，动手测试是最基本的“素质”。写上7、8行代码产生测试数据，然后分别写上2行代码就能测试DataTable筛选表达式和Linq查询所需要耗费的时间值几分钱？！面对最基本的两个信手拈来的查询表达式，不动手，只支嘴儿，这样的状态通常都不是你真实地在进行一个费时几个月的研发中，而是你只想临时起意想一个办法靠写一点点文字而赚一点关注的时候。