数据库越来越大，越来越慢
不到一年，数据库容量已经到6G了，查询速度越来越慢，

到底怎样设计好，能不能设计成这样，超过一年的时候自动换一个文件保存，查询的时候可以指定日期，
例：
2011的数据保存到 2011文件里
2012的时候自动换到2012文件里

查询的时候可以指定文件，比如我想查2011年的数据，可以直接在2011文件里查，这样速度就好一些

------解决方案--------------------
你可以把以前的数据转移到备份库.
------解决方案--------------------
SQL2000 性能有点低，升级到SQL2008吧
还有你说的分表问题，这是可以的，可以按年建表，或者按月建表，更或者你可以一年一个数据库 等等
如果是在一个表上，那你只能做分区了，分区表可以解决你查询慢的问题。
------解决方案--------------------
换成05或08吧，数据量比较大的表，就使用分区表了

或者你可以多建几个库，然后将此库中数据量比较大的表按日期分出去部分，然后从使用库中删除
就像你说的
2011的数据保存到 2011文件里
2012的时候自动换到2012文件里
也就是2011建个库，2012建个库，。。。，如果需要2012中查询2011库的记录，带上库名就可以了




------解决方案--------------------
两千性能是低了点，我有个帖子，里面有个类似问题，应该可以帮你：
http://topic.csdn.net/u/20120728/17/abb1473b-7e8b-4879-8890-33eaccc395ae.html?seed=925622344&r=79256938#r_79256938

楼主看看别人的回复
------解决方案--------------------
数据库这么大，硬件要跟上才行
------解决方案--------------------
两点建议：
1.升级数据库
2.按年份建表，如:Data_2011,Data_2012。。。
------解决方案--------------------
分区表可以达到分表的性能，应用的sql又完全不用改动
当然，如果实时交易真的不需要往年的数据，是可以手工搬移到别的库，一年搬一次，查询的应用的sql就需要改动了
------解决方案--------------------
2000的话 确实有点难办了
升级库吧

还有数据就是拆表和拆库

把一些业务独立到不同的库。

随着业务的发展，这样的架构会带来性能瓶颈，当业务增长到一埞的程度之后，服务器可能会遇到性能瓶颈，这时候需要考虑使用更多的服务器来分担压力，过于集中的数据库会阻碍这种处理形成制约。


另外，过于庞大的数据库，在管理和维护上也不太方便，例如，为了恢复某个时间点的某种业务数据，可能不得不恢复一个庞大的数据库，而一旦数据库出现故障，影响的业务范围也非常广

------解决方案--------------------

探讨

2000的话 确实有点难办了
升级库吧

还有数据就是拆表和拆库

把一些业务独立到不同的库。

随着业务的发展，这样的架构会带来性能瓶颈，当业务增长到一埞的程度之后，服务器可能会遇到性能瓶颈，这时候需要考虑使用更多的服务器来分担压力，过于集中的数据库会阻碍这种处理形成制约。


另外，过于庞大的数据库，在管理和维护上也不太方便，例如，为了恢复某个时间点的某种业务数据，可能不……

------解决方案--------------------
才6G，算什么大。。。。。
优化下sql，加加索引，一般就能搞定了。
------解决方案--------------------

探讨

才6G，算什么大。。。。。
优化下sql，加加索引，一般就能搞定了。

------解决方案--------------------
SQL Server 强大的分区技术(使用语句检测和优化数据库 （MSSQL个人笔记之数据库优化之路 三）

探讨

引用:
SQL2000 性能有点低，升级到SQL2008吧
还有你说的分表问题，这是可以的，可以按年建表，或者按月建表，更或者你可以一年一个数据库 等等
如果是在一个表上，那你只能做分区了，分区表可以解决你查询慢的问题。


我是楼主：
我想再问下，怎样做分区表。有没有详细的文档，谢谢

------解决方案--------------------
还没我一张表大呢
------解决方案--------------------
你可以 写个作业，每个月产生一张新表，这张表存放上月的数据，然后再新表上创建相关索引，来提高查询速度。
或在按你想要的结果（比如 按年来存放数据。思路和上面按月存放数据一样）。

以前在 2000上的经验就是 每个月初将 上月的数据存放到历史（新建）表中，这个历史表作为只读表来供查询分析数据使用。
------解决方案--------------------

探讨

SQL2000 性能有点低，升级到SQL2008吧
还有你说的分表问题，这是可以的，可以按年建表，或者按月建表，更或者你可以一年一个数据库 等等
如果是在一个表上，那你只能做分区了，分区表可以解决你查询慢的问题。

------解决方案--------------------
另外，1年了，应该有做索引的rebuild吧，定期做索引碎片整理
------解决方案--------------------

探讨