大量数据交互问题，SQL Server不堪重负。（大家给点意见）
需求我也不好形容。总之并发量几百到几千。每个并发100毫秒左右查询一次数据库，得到结果后再转存到另外一个表，这样一个请求就算成了。否则HTTP连接一直保持着，直到HTTP超时。

SQL Server  几十的并发连接数网站基本就挂了。
最后我改用static DataTable 做为用户交互数据临时存储，结果100多的并发又挂了。
就开始出现各种错误，估计还是超出负载能力。可以肯定不是代码缺陷，因为连接数少的时候不会有任何问题。


还有什么方法能拿来做临时数据交互的，效率越高越好。 比如大型网络游戏，不可能都是即时些数据库读数据库吧。
------解决方案--------------------
你们公司缺少架构师，至少一个不错的程序员。

你们缺乏理论和经验，在瞎“优化”。

消减并发，消减峰值，缓解读写竞争，建立索引。。。

说起来容易，做起来不简单。


------解决方案--------------------
看得不是很明白，不过看你的描述对数据库的优化还是没有概念，或者说没看到你用缓存的意思，一个静态变量有缓存的雏形，但是远远不够。因为这种优化跟你的架构需求紧密相关，最好自己先看看数据库缓存方面的知识。
------解决方案--------------------
不知道你的所谓“数据交互”具体是做什么。即使最简单的事情，有人也会比别人低效10万倍。例如你不进行索引，而是胡乱顺序查找，这就会很可能慢10万倍。再加上比较差的流程，那么就再乘上100倍也不为过。
------解决方案--------------------
聊天的东西 ，如果不需要记录历史, 那就别用数据库了. 消息队列 。缓存 。都是解决方案.

另外数据库建好索引.
------解决方案--------------------

引用:

8楼详细需求.

看起来像是个通过服务器实时聊天的需求。
这种需求服务器端不应该同步Sleep反复查询，应该采用异步请求，由数据更新事件激活查询集合，同时进行连接超时（比如一分钟）检测。
在这种情况下，如果DataTable如果造成CPU负担过大，应该使用动态数组实现O(1)定位。
------解决方案--------------------
无语，竟然这样搞……
原来楼主是要做HTTP的即时信息

建议楼主去搜索一下 COMET 模型 利用HTTP的长连接，模拟类似于TCP/IP 的 “HTTP推送”，其实也就是得用楼上说的异步响应，做下客户标识处理，数据库要做的事情只需要做好消息记录，不再做响应查询

记得博客园的 老卢 的WEBIM就是基于 COMET的，非常不错