SQL SERVER有2千万条记录的软硬件设计问题

来源：百度知道 编辑：UC知道 时间：2024/05/18 15:33:06
服务器不是很牛，p 4 3.0e，内存1G，硬盘是阵列0
－－－
现在的问题是，数据一共有40来个表，每个表大概6万条记录，每条记录的每个字段都是一个产品名，约8个字段（每个字段的值长度不超过50个字节）。

问题来了：如果我要对数据进行检索：

1， 这一共的记录就是40x60000共2千多万条记录！
如果查询，服务器是不是要很牛？
或者说，速度肯定会遇到瓶颈（相当于全文检索了）

2，我是否有必要先合并这40个表？
这么快就有回答了，感谢！
这种检索不能避免，因为产品型号有这么多。。。。 ：（

----------
不能避免,而且这40个表包含8个字段, 每查询一次,每个字段都得查询一次

服务器已经升级为4G内存。

我觉得如果是这种大量检索的项目，不如使用全文检索功能，或者用搜索来做

换个角度来做设计

当然我不了解需求，我只是谈一下个人看法

//-------------------------------------------------------

这种全文检索，如果还用查询语句去做，似乎不是那么合理吧

如果这样反复做全表扫描

这样的普通pc恐怕是无法承受的

我不知道是不是你们业务上特殊的情况导致这样的需求

但是我觉得单表6w条数据，通常来说是很轻量的

40x60000共2千多万条记录！这种检索情况我不知道能不能避免，这个是什么概念？

240万个400B是吧
那用VB做个查询+WEBSERVER
内存 配置16G
CPU上个四核心
秒速解决查询
再用WEBSERVER反馈OK,解决

用现有的服务器试试不就知道了

2000万的数据，确实不小了，楼主的配置，即使上到自强服务器，意义也不大。而2000万短时间无法寄希望于索引得优化，
唯一能作的，最好编写一个id，分段查询，这样以避免sql超时，以及太多内存消耗情况。存储过程对于这种简单的检索，意义也不是很大

上sql集群可能解决问题，但是那毕竟不是我们所能承受的，尤其是一般企业和单位。

mark并学习，等待高手出现！！！！！！！！！！！！！！！！！！！！！