Dictionary<string, Int32> dic = new Dictionary<string, Int32>();
            Random rnd=new Random ();
            for (int i = 0; i < 500000; i++)
            {
                dic[Guid.NewGuid().ToString() + Guid.NewGuid().ToString()] = rnd.Next();
            }
            System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch();
       

            for (int i = 0; i < 2; i++)
            {
                sw.Reset();
                sw.Start();
                List<string> list = new List<string>();
                foreach (KeyValuePair<string, int> key in dic)
                {
                    if (key.Key.Contains("dadf"))
                    {
                        list.Add(key.Key);
                    }
                }
                sw.Stop();
                
            }

            System.Diagnostics.Debug.WriteLine(sw.ElapsedMilliseconds.ToString());

------解决方案--------------------
你大方向搞错了，别人想引导你，你还不愿意听。虽然有些话不中听，有些人喜欢盛气凌人。该听还得听。乖。。

------解决方案--------------------
词库是需要维护的，每个行业可以定义自己专有的词库
有些词你是不用考虑的
为了某些很小的词，浪费很大的性能，划不来。

------解决方案--------------------
查子串其实是很不专业的做法。效率极其低下，资源浪费极其严重。

正常说来，(那些专业的搜索网站)会先建立一个关键词词典，
然后通过二分法在词典中查找关键词。
lucence大致也是这个原理。

所以sp1234说的也没错。



------解决方案--------------------
良药苦口，虽然被喷的滋味很难受，但其实是帮你提高，你该感谢才是啊

------解决方案--------------------
C#处理楼主所说的类似sql的like有优势?我倒是认为决定性能的是算法(设计方案)

稍微复杂一点的需求,往往其设计的实质就是分多步(多层)去实现,
并且可以在过程中根据不同的自己采用不同的策略处理(也就是多路径)实现,
比如,很多时候,仅仅查出含有首个字符的结果集,已经能把范围缩小n数量级了,
那如果,第一个匹配效果不理想,是否去匹配首2个字符(或者第2个字符),从而尽可能第一次检索就可以得到小一点的子集,
还有,可以尝试自己建立一些检索标的表而不是依赖现成的索引

设计任务就是去实现需求,
而不要目标盯着"代码可读性和性能的取舍",
我所接触的客户好像从来没有要求过"代码可读性"

------解决方案--------------------
DICTIONARY<>本身是基于HASH存放的，是用空间换时间的典型做法，你拿这玩意存放你的数据结果却循环每一个KVP来进行查找。针对你的场景是不合适的。

------解决方案--------------------
全文索引比like的效率高的不是一倍两倍,但是就是有一点如lz所说的分词问题
有一个文件可以配置这个分词的,在准确率可以基本达到要求的情况下还是用全文索引好
如Lz说的谷歌没有分词问题,猜测是对字符串进行全分词(不考虑常用词)后建索引的