none
两张大表,合并显示,如何保证效率 RRS feed

  • 问题

  • 实现效果:两张大表,合并后,按时间顺序显示

    1)环境说明:

    数据库 为 SQL SERVER 2008 R2 EXPRESS;

    TAB1( fieldA, fieldB, fieldC , time1 ), TAB2( fieldD, fieldE, fieldF, time2 )。

    TAB1数据表:

    fieldA, fieldB, fieldC , time1

    1,2,3,2011-9-11 12:02:05

    1,3,5,2011-9-12 15:00:00

    TAB2数据表:

    fieldD, fieldE, fieldF, time2 

    3,4,5,2011-9-12 15:01:17

    2,3,5,2011-9-12 15:00:28

    2)客户端显示效果

    3,4,5,2011-9-12 15:01:17

    2,3,5,2011-9-12 15:00:28

    1,3,5,2011-9-12 15:00:00

    1,2,3,2011-9-11 12:02:05

    即两张表按照时间合并显示,发现当两张表例如均>500w,合并效率低下,现在使用视图实现两张表的合并,以分页形式返回给客户端结果。发现两张表的合并后的排序相当耗时,不知道有什么解决访法


    • 已编辑 Y.P. _ 2011年10月11日 6:45
    2011年10月11日 6:43

答案

  • 这就是个简单的merge操作,需要在时间上有聚集索引,否则就会在tempdb中排序。

    另外啊,EXPRESS版本在某些执行过程上,使用了与其它版本不一样的算法,性能就是要差一些的(不是指这个查询)。


    想不想时已是想,不如不想都不想。
    2011年10月12日 1:02
    版主

全部回复

  • 不知道你的试图使用索引了吗,如果排序,那么就在试图上建立一个以结果为导向的排序规则组合索引。I/O性能会好一些


    星光总能为我指引方向
    2011年10月11日 9:03
  • 除了索引之外,也可以看一下是否硬件性能的瓶颈

    查看一下是磁盘、网络、CPU、内存方面是否对大量的数据造成瓶颈

    2011年10月11日 10:49
  • 不知道你的试图使用索引了吗,如果排序,那么就在试图上建立一个以结果为导向的排序规则组合索引。I/O性能会好一些


    星光总能为我指引方向
    没有使用视图索引,想过用这个方案,还没有用。因为这个方案占用实际的物理空间,所以想知道还有没有其他方法
    2011年10月11日 16:06
  • 这就是个简单的merge操作,需要在时间上有聚集索引,否则就会在tempdb中排序。

    另外啊,EXPRESS版本在某些执行过程上,使用了与其它版本不一样的算法,性能就是要差一些的(不是指这个查询)。


    想不想时已是想,不如不想都不想。
    2011年10月12日 1:02
    版主
  • 这就是个简单的merge操作,需要在时间上有聚集索引,否则就会在tempdb中排序。

    另外啊,EXPRESS版本在某些执行过程上,使用了与其它版本不一样的算法,性能就是要差一些的(不是指这个查询)。


    想不想时已是想,不如不想都不想。

    案例的两张表格是分开存储的,只是在合并结果集时,按照时间排序。使用merge无法实现的吧。
    2011年10月12日 15:23
  •  那还是使用视图索引吧
    it's time to start living the life you are imagined.
    2011年10月13日 3:29
  • merge操作又不是merge语句。

    引自败毒百科:归并操作(merge),也叫归并算法,指的是将两个已经排序的序列合并成一个序列的操作。


    想不想时已是想,不如不想都不想。
    2011年10月13日 7:53
    版主
  • merge操作又不是merge语句。

    引自败毒百科:归并操作(merge),也叫归并算法,指的是将两个已经排序的序列合并成一个序列的操作。


    想不想时已是想,不如不想都不想。

    merge操作,求详解。谢谢
    2011年10月13日 9:08
  • 一两句话说不清楚,我懒得打那么多字,你不需要关心这个,这是sql server做的,你去控制索引就是了。

    需要在时间上有聚集索引,否则就会在tempdb中排序。

    这才是你需要关心的事情。


    想不想时已是想,不如不想都不想。
    2011年10月14日 11:06
    版主
  • 你好

        一张表 >500w,如果对用户的响应速度快,5秒之内属正常吧,就要采取多个手段了。数据库上要调整,程序也要调整。不知道你的数据增量是多少。

        一时也说不过来……


    1+1=The World >>> BLOG=http://blog.csdn.net/liuning800203 >>> Email=liuning800203@hotmail.com

    2011年10月16日 16:06
  • 一两句话说不清楚,我懒得打那么多字,你不需要关心这个,这是sql server做的,你去控制索引就是了。

    需要在时间上有聚集索引,否则就会在tempdb中排序。

    这才是你需要关心的事情。


    想不想时已是想,不如不想都不想。

    两张表格的时间上均为聚集索引了。怡红公子说的使用merge 操作是不是类似内联一样的,由SQL SERVER自己完成操作。

    但是这两张表没有可以作连接的字段,除了需要按照时间合并显示出来,分开储存。

    2011年10月19日 7:44
  • 你好

        一张表 >500w,如果对用户的响应速度快,5秒之内属正常吧,就要采取多个手段了。数据库上要调整,程序也要调整。不知道你的数据增量是多少。

        一时也说不过来……


    1+1=The World >>> BLOG=http://blog.csdn.net/liuning800203 >>> Email=liuning800203@hotmail.com


    我现在是两张表格。均是大表,可以理解为两张均500w。数据增量不多,主要是运行时间久
    2011年10月19日 7:46
  • 写个分页算法就是了
    想不想时已是想,不如不想都不想。
    2011年10月20日 3:02
    版主