大量数据 的 数据库设计问题！

 

银行，现在每天最多会产生1G文本数据，要导入数据库，大约5000万行，这样的数据库该如何设计？  
     
  还要考虑到备份与还原哦！  
     
  还有用户肯定是要查询本年度数据的，可能可以说服他按月查，但估计他们绝不会同意按天查询的  

為提高查詢性能，建合理索引很重要。  
   
  1.確定數據表的操作是大量的查詢還是大量的增刪操作，以此確定使用索引的數目，較多增刪操作應嚴格限制索引數目，如果是較多查詢可以適當增加索引數目。  
  2.嘗試建立索引來幫助查詢。檢查自己的SQL語句，為在WHERE子句中出現的字段建立索引。使查詢引擎快速的定位到指定條件。  
  3.嘗試建立一些復合索引來進一步提高系統性能（修改復合索引將消耗更多的時間，且佔磁盤空間）  
  4.對小型表(記錄少)建立索引可能反而影響性能，因為此時對表掃描操作效率更高。（查詢優化器不能智能處理）  
  5.避免對具有較少值的字段建立索引（如性別）  
  6.避免選擇具有大型數據類型的列作為索引。

 

关于大记录量的数据库设计的问题

公司要将生产出来的每个产品的条形码按照发货单全部存入数据库中。   
  数据结构基本为：单号，日期，下单人，收货人，产品大类，产品规格，产品条形码   
  由于每个产品都有不同的条形码，而每天发出去的产品都有上万个，这样一个月下来数据就有   
  几十万条了，这样以后在对这个表进行查询的时候就会很慢。   
  所以想请教一下，这个表应该怎样设计，才能提高检索效率呢？

1：分当前表和历史表，如当前表根据业务需要保存最近3个月的数据，历史表可以分区保存，如按年分区；这样前端应用要处理查询分表的问题；  
  2：增加必要的索引，提高查询速度；  
  3：建立另外的表把数据预先汇总，如按月、周等；这样要注意明细数据和汇总数据的一致性；  
  4：不要查询大量的数据到前端，应该作必要的分页；

 

可这样设计,一个历史表存所有明细信息,一个单前表存最近一段时间的信息,这个由你们的业务周期来决定,一个按月或周统计的轻度综合表存每月或每周的统计情况,各统计项由你们的业务需求决定,一个按月或年统计的高度综合表.  
  如果要查询大量数据楼上的兄弟说的很有道理分页是好的解决方法,要不然上万条记录的话基本上前面的程序就挂掉了.  

如果是数据仓库的话，选用专门的数据仓库产品，根本不是问题，每个月几十万条的数据量可以算是很小了，我做过的一个项目，每月近千万的数据量，查询速度也比较快

 

创建分区表可提高性能.  
  有关分区表的知识你可以找找资料去.  
  你可以把一个月(或两个月)的数据放在一个分区里.