问题描述
一个winform的下拉控件(例如combox)的绑定数据源可能有十万级别的数据，怎么来做缓存好点？如果在这控件中输入数据然后再去数据库进行模糊匹配的话，可能速度不够快。
解决方案
解决方案二：
你想要完成的是什么功能，常规做法是不会绑十万数组在下拉框里的，你让别人怎么选
解决方案三：
做成autocomplete的功能，到数据库去匹配。缓存就是类似分页读取的效果，解决不了什么问题，不可能让用户去一页一页读取10w条数据
解决方案四：
用DATAGRID绑定数据吧，然后做个分页，10W的数据要读到什么时候？
解决方案五：
你眼睛可以看10万条数据？你在百度搜索框输入的时候模糊提示也就给你显示4条难道百度把它裤里面的全部给你显示出来？
解决方案六：
同意楼上的，在combox中可以设定只能显示10条数据，可以根据输入的信息缩小删选的范围。没必要一次性把所有数据列出给用户使用。
解决方案七：
目前我们的做法是将数据源放在缓存中，用户在combox中输入，我们就去缓存中模糊匹配，这样比直接去数据库取要速度快吧？有没有更好的办法？或者有类似的开源框架？或者对于我们目前的机制有什么好的更新缓存的策略么？
解决方案八：
引用6楼letyougo的回复:
目前我们的做法是将数据源放在缓存中，用户在combox中输入，我们就去缓存中模糊匹配，这样比直接去数据库取要速度快吧？有没有更好的办法？或者有类似的开源框架？或者对于我们目前的机制有什么好的更新缓存的策略么？
假设你缓存在一个List<>里面combox.Items.Clear();intcount==0；foreach(varvinList<>){if(匹配成功)Combox.Items.Add(v);count++;if(count==10)break;//匹配如果有十个了就跳出}
解决方案九：
解决方案十：
首先，这10W条数据，是变更不太频繁的，才会使用缓存。一直变更的数据，不建议使用缓存。（当然如果你对缓存进行变更操作，然后凌晨同步也不是不可以。）其次，正像楼上说的，10W条数据，你是不可能放到Cobobox里的，屏幕也塞不下。还是模糊查询吧，搜索出匹配的前十条显示出来。做好sql的查询性能检测，检查执行计划，注意索引的运用和sql语法。