sql 表数据在一亿条以上 怎么优化

假设表A数据经过一年后达到一亿  如何优化

听别人说 数据库有这个功能，可以把历史的分开例如表中只存最近一个月的 

但是查询表A的 还能查到一个月以前的 

大概意思就是这个   会的帮帮忙 不会的帮顶下

30 个解决方案

#1

说的是分区表，看看联机丛书吧。

#2

如果一年前的只是备份待查,分离出来另存.
如果一年前的会用到,但用得少,用分区.
如果一年前的仍然要频繁使用,用分区,但要加一个磁盘.

#3

以主键水平分割表！

#4

联机丛书

#5

联机丛书

#6

经楼上几位回答查找的相关资料 可以解决问题
http://msdn.microsoft.com/zh-cn/library/ms345146(d=printer,v=SQL.90).aspx

http://topic.csdn.net/u/20091021/16/ed85f7f6-1d92-478b-80fd-6661261baedc.html

http://msdn.microsoft.com/zh-cn/library/ms345146.aspx

http://www.cnblogs.com/sunfny/archive/2011/01/25/1944425.html

#7

引用 6 楼 liyangfd 的回复:

经楼上几位回答查找的相关资料 可以解决问题
http://msdn.microsoft.com/zh-cn/library/ms345146(d=printer,v=SQL.90).aspx

http://topic.csdn.net/u/20091021/16/ed85f7f6-1d92-478b-80fd-6661261baedc.html

http://msdn.micros……

恭喜

#8

如果交易（新增）业务不涉及旧数据，可以把旧数据自动搬移到另一个表甚至另一个库或另一个服务器
历史表会很大，但是只查询，而且不在一个表、库、服务器，基本不影响交易

如果交易要求旧数据存在，则不用分开，直接把A表改为分区表

#9

如果交易（新增）业务不涉及旧数据，可以把旧数据自动搬移到另一个表甚至另一个库或另一个服务器
历史表会很大，但是只查询，而且不在一个表、库、服务器，基本不影响交易

如果交易要求旧数据存在，则不用分开，直接把A表改为分区表

#10

好呀，解决了！

#11

好呀，解决了！

#12

等我实验完成后在结帖子

#13

该回复于2011-12-28 10:02:02被版主删除

#14

该回复于2011-12-28 10:02:32被版主删除

#15

如果是日志数据（随时间增长必然会增长的），分表是必然的，因为总有大到没法运行的一天，分区表只能是个辅助，对其作用不要期望太高

#16

上亿条是一定要分区的，如果是2000的话你可以分表管理，如果是2005或以上你就做一个水平分区就ok了。

#17

该回复于2011-12-28 10:29:52被版主删除

#18

历史数据太多的话 就需要分库 甚至分服务器。

#19

该回复于2011-12-28 10:32:47被版主删除

#20

该回复于2011-12-28 10:31:55被版主删除

#21

学习分区先.....

#22

现在数据库有自己的分区功能，不过要慎用。

#23

历史数据太多的话 就需要分库 甚至分服务器。

#24

木有遇到的，每天就三四十万条 在那里搞

#25

该回复于2011-12-30 09:03:00被版主删除

#26

该回复于2012-01-04 13:14:51被版主删除

#27

另外分一个历史库出来

#28

该回复于2012-01-04 10:18:24被版主删除

#29

建议分区吧

#30

现在用的大一点的表都是20多亿条数据，还是大宽表，没有分区。。。