今日小弟在CSDN论坛里发了个“500W数据分页性能测试”的帖子，想不到引起众多朋友的关注，于是打算写份心得体会~~~~实际我测试的时候用的1000W数据测试，不过小弟的机器只有512的内存，用1000W，性能虽说也还很好，但我的机器却不能再干别的了，于是改为500W演示给大家看（我的机器总不能长期不用呀，呵呵，我还得写程序，还得开巨大的Vs.net2005），但性能几乎没什么差别！只是1000W启动更慢，内存消耗更大~~500W消耗90多M，1000W就要消耗180多M……
帖子地址:http://community.csdn.net/Expert/topic/3132/3132779.xml?temp=9.943789E-02
首先数据量大了之后，我们先分析下，瓶颈在哪里？我们就以比较经典和流行的那个存储过程分页作为例子~~那个存储过程都干了些什么呢？他建立了一个临时内存表，用来存放ID，致使ID连贯，可以任意获取某个位置的数据，但如果数据量十分大了之后，比如500W或者1000W，即便只读ID也是很费劲的~~~那解决问题的关键就在于，如何不读这个ID，数据库那边是不好操作了，于是，我们可以把这个ID索引读到程序中来，然后根据这个索引读数据，不就快了吗？慢也就是第一次的时候慢~~ 于是，我读取了这个ID列到程序总，并组织成为一个ArrayList，然后根据访问这个AL的元素定位需要数据的真实ID，有了ID就好办了，再根据ID获取数据，还困难吗？
接下来，出现了新的问题，如果数据频繁更新怎么办？重新建立AL？不，不能怎么死脑筋，换个方式？我为什么不能在更改数据的同时更改这个AL呢？这就不用重新建立了，OK，核心思想就是这样~~
进一步就是一些麻烦的过程，还好没什么难度，只是麻烦而已，那就是每次更新数据库的同时同步更新缓存中的AL，要实现这个，是有一点麻烦~~于是我将这些操作全部封装，成了一个实体控制类，用DataRow和DataTable作为实体，内部实现了增删改的方法，并且在实现的同时，同步更新了AL
大概的原理就是这样，其实很简单，只是思路问题而已~~~
说说这个方法的缺陷吧，有，当然有，通过这个方法获取数据，获取的规则，比如排序，比如过滤，必须预先指定，不能随时更换~~~
关于进一步提高，小弟想到一个办法，还可以进一步提高性能，但现在还没实现，还在构思，就不多说了，如果实现成功再说吧，免得浪费大家的时间~~~
最后，介绍下我的这个实体控制类^_^
?1、实现了缓存加速功能，上面说的办法就是核心思想，当然也支持常规的存储过程和ID过滤方式，并且集成好了的。
2、不用XML，可以自动根据数据库结构，建立映射对象。
3、解决数据并发更新冲突（还在制作中）
4、可以根据对象建立数据表。
5、用DataTable和DataRow作为实体，我觉得蛮好，通用且方便~~~~
6、单条查询、集合查询、数据的单条和集合的“增加”“删除”“修改”这些自然是实现的了
不知道算个什么，呵呵，如果有需要的朋友可以与我联系~~~
cnlamar
hotmail.com
------------------------------------
第二阶段：
首先总结一下前面完成的结果：
1、一些前面介绍过的特性就不说了。
2、进一步封装，提供策略机制，简化使用难度，现在用这个东西实现大数据量分页，可以说是小菜一碟，随便看两眼就会用了，呵呵。
3、引入预读错开机制，避免程序开始建立索引时会消耗很长时间，而用户在这段时间却无法获得数据
4、前面的实现已经进一步稳定，并且实现了异步回调等功能，以保证数据更新冲突时能正确的处理问题。
下面将考虑使用.net2.0的特性让性能得到更大的提升，大致的考虑如下：
1、采用泛型特征建立索引集，这样就没有box/unbox的开销了，并且索引将存储于堆之中，而不是堆栈之中，性能自然会有大幅度的提升。
2、采用泛型特征按强类型存储实际数据，那么数据“增删改”的时候，性能有望继续提升。（近日正在想办法联系到MS中开发DataSet的工作人员，希望得到他们的支持，直接在将来的版本中支持强类型的数据集）
3、将索引再度分页，可以是负载量进一步提高，此方法以前就尝试过，由于修改太多，暂时没有执行，打算下一步花半天的时间，把这个支持好好的做做，按预计，我的机器支持上亿的数据也不是不可能，至少可以支持到5千万，如果可以把内存扩到1G，那支持1亿数据应该是没有什么问题的。
还没有想到解决办法的问题：
1、多种排序模式下，如果要建立多个索引，如何将多个索引自动关联更新？手工的话，就不好了，自动的话，到目前没有想到一个好的方法来解决这个问题，如果你有灵感，请告诉我，谢谢。