大量数据交互问题，SQL Server不堪重负。（大家给点意见）
需求我也不好形容。总之并发量几百到几千。每个并发100毫秒左右查询一次数据库，得到结果后再转存到另外一个表，这样一个请求就算成了。否则HTTP连接一直保持着，直到HTTP超时。
SQL Server 几十的并发连接数网站基本就挂了。
最后我改用static DataTable 做为用户交互数据临时存储，结果100多的并发又挂了。
就开始出现各种错误，估计还是超出负载能力。可以肯定不是代码缺陷，因为连接数少的时候不会有任何问题。
还有什么方法能拿来做临时数据交互的，效率越高越好。 比如大型网络游戏，不可能都是即时些数据库读数据库吧。
[解决办法]
你们公司缺少架构师，至少一个不错的程序员。
你们缺乏理论和经验，在瞎“优化”。
消减并发，消减峰值，缓解读写竞争，建立索引。。。
说起来容易，做起来不简单。
[解决办法]
看得不是很明白，不过看你的描述对数据库的优化还是没有概念，或者说没看到你用缓存的意思，一个静态变量有缓存的雏形，但是远远不够。因为这种优化跟你的架构需求紧密相关，最好自己先看看数据库缓存方面的知识。
[解决办法]
不知道你的所谓“数据交互”具体是做什么。即使最简单的事情，有人也会比别人低效10万倍。例如你不进行索引，而是胡乱顺序查找，这就会很可能慢10万倍。再加上比较差的流程，那么就再乘上100倍也不为过。
[解决办法]
聊天的东西 ，如果不需要记录历史, 那就别用数据库了. 消息队列 。缓存 。都是解决方案.
另外数据库建好索引.
[解决办法]
