目前服务器：
至强3.06G 4G内存 ，硬盘也是对应的那种服务器硬盘吧，就是目前比较主流的服务器
SQL2005 数据库，主表 100W左右的数据
用到like搜索
我已经手动把SQL缓存改为3G。目前日IP访问量 800左右
（以后数据量和IP访问量都会增加）（很明显目前硬件配置是不够的··因为以前没相关经验··我不知道什么样的配置可以达到用户能很好的体验）1、目前的情况，单独搜索，如果SQL刚重启，还可以忍受，大概几秒左右。但是随着访问者搜索增加，SQL会死在那边，一天的话，可能还不至于完全死机··但是会很慢很慢··经过一天后，操作服务器就会很慢，应该是SQL资源应付不过来，死在那边了，重启SQL后，资源释放，然后勉强又开始新的一天。具体机理我不是很说的清楚，懂的大侠也可以帮我分析一下。现在需求对服务器进行升级，要怎么样的升级，才能很好的达到用户体验。
（不要说配个什么几十万上百万的那种服务器，目前对我们经济方面不太现实）所以希望给一些中肯的建议。2、如果把内存加大到32G或者64G，能否很好的改善情况，大概百万数据like匹配搜索一次，要多少时间？！并发能维持几个？！3、配高级服务器对我们可能有点困难，但是也不介意说，有此类经验的大侠，能具体的告之一个大概什么价位什么服务器，就能比较好的应付。最好响应时间能维持在5秒之内。4、然后，也是我们目前在着重考虑的，就是我们最上面提到的服务器是有不少台，大概7-8台。用怎么的程序步骤和数据库分布，能够很好的利用起这些服务器，组建成一个服务器群，实现类似GOOGLE搜索一样，分开同步搜索数据，然后汇总显示。用什么好的方式拆分，然后怎么分布同步搜索并汇总显示，分页要怎么处理···哪怕是提供些这方面的相关资料也行···项目是 VS(C#)+SQL2005；是B/S结构。SQL数据存取处理都是通过存储过程的。
我编号的是有这么几个疑问··红色字是我疑问的内容···希望大虾们能对所知道的方面给与指点帮助···如果认为打字无法说清 请留个QQ 或者 联系方式一起探讨也可以··
至强3.06G 4G内存 ，硬盘也是对应的那种服务器硬盘吧，就是目前比较主流的服务器
SQL2005 数据库，主表 100W左右的数据
用到like搜索
我已经手动把SQL缓存改为3G。目前日IP访问量 800左右
（以后数据量和IP访问量都会增加）（很明显目前硬件配置是不够的··因为以前没相关经验··我不知道什么样的配置可以达到用户能很好的体验）1、目前的情况，单独搜索，如果SQL刚重启，还可以忍受，大概几秒左右。但是随着访问者搜索增加，SQL会死在那边，一天的话，可能还不至于完全死机··但是会很慢很慢··经过一天后，操作服务器就会很慢，应该是SQL资源应付不过来，死在那边了，重启SQL后，资源释放，然后勉强又开始新的一天。具体机理我不是很说的清楚，懂的大侠也可以帮我分析一下。现在需求对服务器进行升级，要怎么样的升级，才能很好的达到用户体验。
（不要说配个什么几十万上百万的那种服务器，目前对我们经济方面不太现实）所以希望给一些中肯的建议。2、如果把内存加大到32G或者64G，能否很好的改善情况，大概百万数据like匹配搜索一次，要多少时间？！并发能维持几个？！3、配高级服务器对我们可能有点困难，但是也不介意说，有此类经验的大侠，能具体的告之一个大概什么价位什么服务器，就能比较好的应付。最好响应时间能维持在5秒之内。4、然后，也是我们目前在着重考虑的，就是我们最上面提到的服务器是有不少台，大概7-8台。用怎么的程序步骤和数据库分布，能够很好的利用起这些服务器，组建成一个服务器群，实现类似GOOGLE搜索一样，分开同步搜索数据，然后汇总显示。用什么好的方式拆分，然后怎么分布同步搜索并汇总显示，分页要怎么处理···哪怕是提供些这方面的相关资料也行···项目是 VS(C#)+SQL2005；是B/S结构。SQL数据存取处理都是通过存储过程的。
我编号的是有这么几个疑问··红色字是我疑问的内容···希望大虾们能对所知道的方面给与指点帮助···如果认为打字无法说清 请留个QQ 或者 联系方式一起探讨也可以··
ZDNet 软件频道 更新时间：2007-08-29 作者：xiaozhao 来源：赛迪网
本文关键词：集群 数据库 SQL Server
很多组织机构慢慢的在不同的服务器和地点部署SQL Server数据库——为各种应用和目的——开始考虑通过SQL Server集群的方式来合并。 将SQL Server实例和数据库合并到一个中心的地点可以减低成本，尤其是维护和软硬件许可证。此外，在合并之后，可以减低所需机器的数量，这些机器就可以用于备用。 当寻找一个备用，比如高可用性的环境，企业常常决定部署Microsoft的集群架构。我常常被问到小的集群(由较少的节点组成)SQL Server实例和作为中心解决方案的大的集群哪一种更好。在我们比较了这两个集群架构之后，我让你们自己做决定。 什么是Microsoft集群服务器 MSCS是一个Windows Server企业版中的内建功能。这个软件支持两个或者更多服务器节点连接起来形成一个“集群”，来获得更高的可用性和对数据和应用更简便的管理。MSCS可以自动的检查到服务器或者应用的失效，并从中恢复。你也可以使用它来(手动)移动服务器之间的负载来平衡利用率以及无需停机时间来调度计划中的维护任务。 这种集群设计使用软件“心跳”来检测应用或者服务器的失效。在服务器失效的事件中，它会自动将资源(比如磁盘和IP地址)的所有权从失效的服务器转移到活动的服务器。注意还有方法可以保持心跳连接的更高的可用性，比如站点全面失效的情况下。 MSCS不要求在客户计算机上安装任何特殊软件，因此用户在灾难恢复的经历依赖于客户-服务器应用中客户一方的本质。客户的重新连接常常是透明的，因为MSCS在相同的IP地址上重启应用、文件共享等等。进一步，为了灾难恢复，集群的节点可以处于分离的、遥远的地点。 在集群服务器上的SQL Server SQL Server 2000可以配置为最多4个节点的集群，而SQL Server 2005可以配置为最多8个节点的集群。当一个SQL Server实例被配置为集群之后，它的磁盘资源、IP地址和服务就形成了集群组来实现灾难恢复。 SQL Server 2000允许在一个集群上安装16个实例。根据在线帮助，“SQL Server 2005在一个服务器或者处理器上可以支持最多50个SQL Server实例，”但是，“只能使用25个硬盘驱动器符，因此如果你需要更多的实例，那么需要预先规划。” 注意SQL Server实例的灾难恢复阶段是指SQL Server服务开始所需要的时间，这可能从几秒钟到几分钟。如果你需要更高的可用性，考虑使用其他的方法，比如log shipping和数据库镜像。 单个的大的SQL Server集群还是小的集群 下面是大的、由更多的节点组成的集群的优点： ◆更高的可用新(更多的节点来灾难恢复)。 ◆更多的负载均衡选择(更多的节点)。◆更低廉的维护成本。 ◆增长的敏捷性。多达4个或者8个节点，依赖于SQL版本。 ◆增强的管理性和简化环境(需要管理的少了)。 ◆更少的停机时间(灾难恢复更多的选择)。 ◆灾难恢复性能不受集群中的节点数目影响。 下面是单个大的集群的缺点： ◆集群节点数目有限(如果需要第9个节点怎么办)。 ◆在集群中SQL实例数目有限。◆没有对失效的防护——如果磁盘阵列失效了，就不会发生灾难恢复。 ◆使用灾难恢复集群，无法在数据库级别或者数据库对象级别，比如表，创建灾难恢复集群。 虚拟化和集群 虚拟机也可以参与到集群中，虚拟和物理机器可以集群在一起，不会发生问题。SQL Server实例可以在虚拟机上，但是性能可能会受用影响，这依赖于实例所消耗的资源。在虚拟机上安装SQL Server实例之前，你需要进行压力测试来验证它是否可以承受必要的负载。 在这种灵活的架构中，如果虚拟机和物理机器集群在一起，你可以在虚拟机和物理机器之间对SQL Server进行负载均衡。比如，使用虚拟机上的SQL Server实例开发应用。然后在你需要对开发实例进行压力测试的时候，将它灾难恢复到集群中更强的物理机器上。 集群服务器可以用于SQL Server的高可用性、灾难恢复、可扩展性和负载均衡。单个更大的、由更多的节点组成的集群往往比小的、只有少数节点的集群更好。大个集群允许更灵活环境，为了负载均衡和维护，实例可以从一个节点移动到另外的节点。
我有的服务器和您差不多。也你没出现这样的情况。优化索引，也可以重新分布一下tempDB的数据文件，服务器的磁盘扇区对齐，还有最好磁盘的形式最好是RAID10可以提高读写的性能。
呵呵，索引该优化的已经优化，其实这个是个连续问题，我从去年就开始问了，当然问题的本质都不一样。
搜索当然不单单是关键词，还有类别，主题，国家什么的··这些都做了索引，如果不输入关键词单一访问是没什么问题。但是like的话，全文遍历搜索了··比较慢，卡机是因为多用户并发搜索，导致了服务器SQL资源耗尽吧，不知道是否可以这么说，表象上是这样，因为CPU占的不高，但是服务器已经死在那里了，重启SQL就好了，应该是SQL死锁了。
然后针对你：重新分布一下tempDB的数据文件，服务器的磁盘扇区对齐，还有最好磁盘的形式最好是RAID10可以提高读写的性能。----能表述的详细点吗？这方面的知识比较欠缺，不是很理解您说的意思····
alter database tempdb modify file(name=tempdev,filename='F:\DBData\tempdb.mdf')
alter database tempdb modify file(name=templog,filename='E:\DBLog\tempdb_log.ldf')
ALTER DATABASE [TEMPDB]
ADD FILE
(NAME = N'TEMPDEV1'
, FILENAME = N' F:\DBDATA\tempdb01.mdf'
, SIZE = 50
, FILEGROWTH = 50MB) ALTER DATABASE [TEMPDB]
ADD FILE
(NAME = N'TEMPDEV2'
, FILENAME = N'F:\DBDATA\tempdb02.mdf'
, SIZE = 50
, FILEGROWTH = 50MB) ALTER DATABASE [TEMPDB]
ADD FILE
(NAME = N'TEMPDEV3'
, FILENAME = N'G:\DBDATA\tempdb03.mdf'
, SIZE = 50
, FILEGROWTH = 50MB) ALTER DATABASE TEMPDB MODIFY FILE
(NAME = TEMPDEV
,SIZE=50MB
, FILEGROWTH = 50MB)
GO
扇区对齐.
在对NTFS格式化的时候,需指定NTFS Allocation Unit Size=64K 磁盘分区完成后，需要检验磁盘分区大小和RAID上的offset
当前RAID的offset可以通过下面的vbs脚本查看
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMIService.ExecQuery( _
"SELECT * FROM Win32_DiskPartition",,48)
For Each objItem in colItems
Wscript.Echo "Disk: " & objItem.DiskIndex & " Partition: " & objItem.Index & " StartingOffset: " & objItem.StartingOffset/1024 & "KB"
Wscript.Echo
Next 注：运行上面得vbs脚本弹出对话框显示STARTINGOFFSET: 64KB，说明此服务器上的RAID 的offset设置正确。
我也说关键词太长了··但是“有人”一定要这样··有些事情是没办法的，只能尽量优化。哎··全文索引不是没考虑过，但是数据更新频繁，不太适合全文索引的吧估计东升哥的意思是把你的tempdb数据文件放到其他盘去存放的意思..：我大概理解他的意思的，就是做个磁盘矩阵，模式用RAID10。然后加大内存，就是I/O的吞吐量增大··1、然后我这里有个疑问，这样一台至强服务器就能很好的处理百万数据搜索了吗？？CPU会不会处理不过来？！！2、数据更新频繁也适合做全文索引效果好？！
目前cpu压力多大？io队列如何？
2、CPU是单个四核的 至强系列 3.06,
3、cpu压力多大？··其实并发（几个说实话没研究过）操作搜索数据的时候，CPU跳到95%左右，如果并发过多SQL死锁了，CPU好像就不工作一样，5%左右，好像不占CPU资源了
4、IO队列如何，这个我不知道怎么查看，请提示一下