还给出了以下索引建议:CREATE NONCLUSTERED INDEX [_dta_index_BCardPurses_16_658101385__K2_4] ON [dbo].[积分账户表] 
(
[积分类型] ASC
)
INCLUDE ( [积分]) WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]CREATE STATISTICS [_dta_stat_658101385_2_1] ON [dbo].[积分账户表]([积分类型], [ID])

解决方案 »

  1.   


    这个索引,不太合理吧,你是要查询某个主账户的 积分,那么就应该是:CREATE NONCLUSTERED INDEX [_dta_index_BCardPurses_16_658101385__K2_4] ON [dbo].[积分账户表] 
    (
        主账户号,[积分类型] ASC
    )
    INCLUDE ( [积分]) 
      

  2.   

    是的,这个表就4个字段。你的语句是不是类似这样的:select sum(积分)
    from 积分账户表
    where 主账户号  = 'xxx' and  积分类型='yyy'
      

  3.   


      开始没有留意。  创建这个统计信息有什么用处?其实就是有利于sql server产生比较好的执行计划。
      

  4.   

    优化器要根据统计信息,然后选择表上哪个索引(如果有多个索引)更加适合这个查询,统计信息的准确性直接影响查询的性能,另外统计信息是描述你表上数据的数据,通过统计信息,优化器可以知道大概你的查询要返回多少数据、where条件中所需的数据大概在表的什么地方等等信息,极其重要
      

  5.   

    是的,这个表就4个字段。你的语句是不是类似这样的:select sum(积分)
    from 积分账户表
    where 主账户号  = 'xxx' and  积分类型='yyy'
    实际使用中我们不会进行sum统计。在存储过程中使用的查询是:select 积分类型,积分 from 积分账户表 p inner join 积分类型表 t on p.积分类型=t.积分类型 where 主账户号 = 'xxx' order by t.优化顺序业务需求是:查找出用户的所有类型积分,然后按优化顺序扣减积分所以,存储过程中会按优化顺序查询出所有类型积分,然后再比较单个类型积分余额是否足够,足够就扣减,不足再从下一次类型积分扣。
    --
    我在想是否有必要在积分账户表直接标记优化顺序,那样就不需要联接积分类型表进行查询了。
      

  6.   

    适当的使用空间换时间的思路是可以的,不过order by的开销会根据你的表数量逐步增大
      

  7.   

    是的,这个表就4个字段。你的语句是不是类似这样的:select sum(积分)
    from 积分账户表
    where 主账户号  = 'xxx' and  积分类型='yyy'
    实际使用中我们不会进行sum统计。在存储过程中使用的查询是:select 积分类型,积分 from 积分账户表 p inner join 积分类型表 t on p.积分类型=t.积分类型 where 主账户号 = 'xxx' order by t.优化顺序业务需求是:查找出用户的所有类型积分,然后按优化顺序扣减积分所以,存储过程中会按优化顺序查询出所有类型积分,然后再比较单个类型积分余额是否足够,足够就扣减,不足再从下一次类型积分扣。
    --
    我在想是否有必要在积分账户表直接标记优化顺序,那样就不需要联接积分类型表进行查询了。那就按照主账户字段建个索引把:create index idx_xxx on 积分账户表(主账户号)
      

  8.   

    如前所述,  为了完成多个类型的循环比较,还在存储过程中使用了游标。 我认为采用游标不是很恰当。 现在积分类型总量有限,最多5个。 在存储过程中使用if语句从1到5分别处理,就是多写几行sql,看起来不美观。
      

  9.   

    2005以上可以用CTE来循环,没必要高游标