单表数据量过大的解决办法
向大家咨询一下．如果单表数据表非常大，比如超过1000万记录，为了更好地管理数据库，采用哪种方案比较好呢？比如使用分区，但是分区会增加管理复杂度和成本，有没有更好地解决办法．比如把一些老旧的历史数据放到其它表中．不知道大家在使用过程中有没有相关的心得，谢谢．


------解决方案--------------------
我们一般都是把历史数据定期转存其他表（一样的表名后加年月例如TABLE201205）归档~
这样该表本年度的查询的压力也小点（90%查询量集中在本年度）,即使查询历史数据也不影响性能，强力推荐！
------解决方案--------------------
看需求，如果需求不限制，那就分表

分区会增加管理复杂度和成本这个很难理解，分区增加不了多少工作，如果需求要求必须单表，分区是解决在千万到几亿数据量的比较合适的方法

可能更大数据量还是要回到分的路上，但是可能更多考虑分布式
------解决方案--------------------
我做过一个项目，365*24*60*10000的数据量，数据表15个字段左右大部分是字符型的，表基本上是时间，IP，地点查询为主，然后加统计功能（是个报警日志表）。
采用的方法，日表为数据装载主体，在时间字段建立聚集索引，其他常用检索字段非聚集INCLUDE索引，但是建立日表的同时会更新以统计项为划分的月统计表计算各类数值。生成日表和月表统计每日用作业执行。这样可以保证日表在千万左右数据量，月表（我的应用环境）万级别，日表检索在算法上用的双TOP+二分法检索，2个操作基本上都可以保证在毫秒级别显示结果。
参考下。。。
------解决方案--------------------
1、从结构上来说，分区很有必要，我听过一些培训，微软给客户的建议是一个表如果大小超过50M，那就建议分区了。而且分区几乎是“一次性”的事情，不会增加什么管理成本。
2、可以使用归档方式管理历史数据。其实你的数据量不大啦，我以前做银行系统，单表就2亿多，40G的大小。
3、优化你的语句和设计。
4、结合你的业务去晚上结构。有时候可以考虑用空间去换时间。