最近遇到一个头疼问题，Sql2005数据库其中有张表的数据在2000万左右，关键问题是针对这张表的访问非常频繁，大约每秒钟访问5次，并且每次读取一条的时间不能超过150毫秒，我曾经试过分区、建立索引，有为老大说索引并不是越多越好，多了反而变得慢了，于是目前只有4个所以，现在有个问题是数据库文件巨大，在1500万数据的情况下，文件已经60G了，我数据库设置的是简单模式，不知道各位老大有什么好的优化解决方案？？？再一个问题是在生产的时候，因为实时访问速度很快，如果有其他用户通过某个客户端查询数据库，当查询与这张大表有关的业务时，生产车间的生产速度就会瞬时慢下来，有什么解决方案可以不影响生产车间的速度呢？？？？针对上面的问题，曾经有人建议我做两个数据库，在这个数据库中做个同步服务，这样的话，会不会对这个在用生产的数据库造成很大的负荷？因为这样的话 我觉得 理论上是 每隔几秒钟 就要去更新 其他数据库的值，所以这个不是很明白，会不会影响效率？？？
再一个问题是聚镞索引问题，聚镞索引影响数据在磁盘的存储位置和排列顺序，那么，如果我改变了聚镞索引中某个字段的值，那么这条数据会不会重新在磁盘上排列？？？如果重新排列的话会不会影响效率呢？？因为我的实时交互太快以上几个问题困扰了好久，各位老大们多多赐教！！多谢多谢~~~另外有什么好的、活跃的SqlServer QQ群，麻烦告知下多谢！！！
再一个问题是聚镞索引问题，聚镞索引影响数据在磁盘的存储位置和排列顺序，那么，如果我改变了聚镞索引中某个字段的值，那么这条数据会不会重新在磁盘上排列？？？如果重新排列的话会不会影响效率呢？？因为我的实时交互太快以上几个问题困扰了好久，各位老大们多多赐教！！多谢多谢~~~另外有什么好的、活跃的SqlServer QQ群，麻烦告知下多谢！！！
只能通过索引和优化语句来提高速度了 可以考虑分区表的
简单模式只能减慢日志增长速度 还是有日志的
在存储过程中，尽量按照索引顺序排列查询条件
索引，少建立
聚集索引建立在最能缩减查询范围，且部分平均的字段上，比如时间然后就是分区表，，尽量分在不同硬盘上还不行，，，就拆表，，拆成历史表，，，或 分类表想办法在业务逻辑上把表拆成多部分，数据库的优化手段用完了，，，就只有从，，，业务，，，或者，，，，程序上想办法
一个历史 一个实时