【原因】
在数据库效率测试的时候，一个SQL的执行情况跟实际的应用场景有关，大部分在开发优先考虑正确性，再考虑效率问题。
在考虑效率问题上，由于时间原因导致无法一次性思考多个方面，而且随着时间和应用的积累导致一系列的问题，而无法在本地重现问题原因，很盲目的找问题的所在，导致多次修改Sql来观察;更重要，你不可能在生产机上做问题分析~只能尽量在本地重现问题~
【模拟问题重现】
抛开其他比如IIS压力、硬件本身之类问题外，对于数据库来说，模拟的就是写入和读取
【模拟参数】
1、每秒写入数据多少条
大数据多少条，比如日志，也许是2000字节之上
常规数据多少条，比如相片地址，一般都是100个字节
日志数据多少条，这类数据数据不大，200字节左右，但频繁
2、每秒读取数据多少次
注意，间隔时间的模拟
为了让情况更真实些，要考虑一定的并发情况。
一个时间刻度上，有多少个写入请求，有多少个读取请求
【模拟程序的要求】
1、有完善的参数设定
2、能保存模拟的参数
3、有日志记录
4、尽量让此程序能独立，仅仅对外部仅仅调用，而非嵌入开发。实在不行，实现此部分的模块化，方便开发模拟情况的程序。
【达到的效果】
运行此软件，能有效的在查询分析器上，看出一些特定环境下的执行情况，重现问题，以及更实时看调试的SQL的执行计划。
争取5月1号之前写出此程序
/*2011-4-11*/
流程描述：
1、启动主程序，进入参数设定和任务启动界面
2、根据参数配置，启动任务-{比如创建新程序或新新进程或新线程}
至于怎么启动任务，需要思考下如何走：
方案一：
创建一个任务，这个任务自身不断创建线程，实现数据库写入和读取的任务
方案二：
创建一个任务，以CMD命令方式启动新的程序，此程序来实现线程的写入和读取数据库
主程序控制启动多少个新的程序，每一个新程序都是在某时间段运行和结束，不会采用循环方式。
方案三：
创建一个任务，以函数指针的方式运行执行函数，此函数实现线程的再次分配任务线程，这一级的线程才实现写入和读取数据库。
优劣：
方案一，耦合性太重，不宜扩展
方案二采用的进程+线程
方案三采用的线程+线程
后两种的差距在一定程度上没有什么影响
个人建议采用方案三
先思考如何读写数据库？