数据库越来越大，愈来愈慢
数据库越来越大，越来越慢不到一年，数据库容量已经到6G了，查询速度越来越慢，到底怎样设计好，能不能设计成这
数据库越来越大，越来越慢
不到一年，数据库容量已经到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的话 确实有点难办了
升级库吧
还有数据就是拆表和拆库
把一些业务独立到不同的库。
随着业务的发展，这样的架构会带来性能瓶颈，当业务增长到一埞的程度之后，服务器可能会遇到性能瓶颈，这时候需要考虑使用更多的服务器来分担压力，过于集中的数据库会阻碍这种处理形成制约。
另外，过于庞大的数据库，在管理和维护上也不太方便，例如，为了恢复某个时间点的某种业务数据，可能不得不恢复一个庞大的数据库，而一旦数据库出现故障，影响的业务范围也非常广
[解决办法]
[解决办法]才6G，算什么大。。。。。
优化下sql，加加索引，一般就能搞定了。
[解决办法][解决办法]SQL Server 强大的分区技术(使用语句检测和优化数据库 （MSSQL个人笔记之数据库优化之路 三）
[解决办法]还没我一张表大呢
[解决办法]你可以 写个作业，每个月产生一张新表，这张表存放上月的数据，然后再新表上创建相关索引，来提高查询速度。
或在按你想要的结果（比如 按年来存放数据。思路和上面按月存放数据一样）。
以前在 2000上的经验就是 每个月初将 上月的数据存放到历史（新建）表中，这个历史表作为只读表来供查询分析数据使用。
[解决办法][解决办法]另外，1年了，应该有做索引的rebuild吧，定期做索引碎片整理
[解决办法][解决办法]你是日志文件增长的过大 还是数据文件大撒
[解决办法]6G的确不算大，优化下SQL先
[解决办法]6G真不算大，还是先从表设计和代码入手，进行优化吧。比如减少表的冗余字段，设置合理的索引，优化查询语句，减少不必要的输入等等。
另外MSSQL2000真的很老了，现在2012都出了，可以考虑升级了。
[解决办法]就是不知道是bs 还是cs 的 若是cs的换数据库软件都要升级的呀
[解决办法]已经可以确定你的软件是老爷爷级的。不知道机器是否老爷爷级的。
6G的数据实在不算多。核心问题应该是SQL语句效率和索引的问题。
[解决办法]哦，才6G，我的都五十多G了，速度还过得去
[解决办法]才6G，我们1个月30G
