数据库最大的表记录超过3000万,每日写入10万,多久重建一次索引比较好?因为重建一次需要花2个小时,所以不想太频繁,各位意见如何?

解决方案 »

  1.   

    每年一个库,每个月一张表,建立适当的索引。
      

  2.   

    给大家推荐个好的技术群  大家一起学习啊32141736
      

  3.   

    每月建一个表不大合适,经常有跨月查询,处理就麻烦了,比如4月10日要差3月20到4月5日之间的数据就不是很方便了。
      

  4.   

    每月建一个表不大合适,经常有跨月查询,处理就麻烦了,比如4月10日要差3月20到4月5日之间的数据就不是很方便了。
    -----------------------------------------------------------------------------------
    对大表按时间分区,建立分区视图,检索视图即可。
      

  5.   

    分区视图的效率如何,可以建立试图索引吗,我担心效率会不会有问题
      

  6.   

    到底是按月建立表好呢,还是按月将上月数据转移到历史库好?两种方法各有什么利弊?
      

  7.   

    对大表按时间分区,建立分区视图,检索视图即可。
      

  8.   

    数据库多少时间重建一次索引比较好? 
    -----------------------------------具體問題具體分析,若索引建立合理,就不用重建了
    所謂合理就是該建主鍵的必須建主鍵,其次要看經常被用來搜索的字段中出現頻率最高的,
    且建立了索引后更新、插入操作所受的影響能夠接受
      

  9.   

    严重关注,我也在考虑分区视图,但是不知性能如何。我们系统最大的表也有3000万记录了,每天不建索引就没办法用,但是重建索引很花时间和系统资源。
      

  10.   

    我同意子陌红尘的做法!!!
      

  11.   

    好大的数据量啊!!!不知道你们的排序和查询是怎么优化的啊?
      

  12.   

    多久重建一次索引比较好
    ---------------------------------这个主要还是要根据碎片的程度来决定了,如果每个碎片都很大完全没必要重建,重组一下就好,联机操作的,很方便,不影响效率个人认为在碎片的平均页数在30%以下就需要重建索引了,我通常都是每天晚上通过循环判断那个索引需要重建
      

  13.   

    可以检测,并对指定的索引进行维护
      

  14.   

    多久重建一次索引比较好
    ---------------------------------这个主要还是要根据碎片的程度来决定了,如果每个碎片都很大完全没必要重建,重组一下就好,联机操作的,很方便,不影响效率个人认为在碎片的平均页数在30%以下就需要重建索引了,我通常都是每天晚上通过循环判断那个索引需要重建
    =================================
    如何监测哪个索引需要维护和重建呢?